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Research  Directions  in  Data  Base  Management  Systems 

by  D.  Tsichritzis 

Computer  Systems  Research  Group 
University  of  Toronto 
Toronto  MSS  1A7 ,  Canada 


Abstract 

Data  Base  Management  Systems  (DBMS's)  have  become  "in  vogue" 
recently.  The  area  is  not  only  fashionable  but  also  very 
important.  The  DBMS  users  have  huge  problems  which  guide  the 
researchers  in  their  work.  In  this  paper  the  most  promising 
areas  for  DBMS  research  are  outlined.  The  proposed  research 
areas  are  all  related  to  other  research  disciplines  in  Computer 
Science . 


* 

In  this  paper  we  take  a  candid  view  of  DBMS  Research, 
hope  that  nobody  gets  upset. 


Let  us 
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"I*  ion 

D^td  Base  Md  naqe  ir.e  lit  Systems  (DBMS's)  have  become  "in  vo'jue" 
recently.  The  area  is  not  only  fashionable  but  also  very 

important.  In  some  aiscipliiies  the  trends  of  research  rest 

pur-ly  on  the  taste  of  the  researchers,  or  the  research  agencies, 
howev-^r,  the  directions  in  DPnS’s  come  straight  from  the 
marketplace.  The  area  was  originally  developed  and  is  heavily 
influericerl  by  the  problems  large  organizations  have  to  manage 

e  f  fee  t  i  vtr  1  y  and  efficiently  large  volumes  of  data.  There  is  no 
sc-iect  group  of  individuals  in  DBMS  who  collectively  aecide  what 
will  be  the  next  problem  to  attack  or  the  next  project  to  start. 

Tiie  users  have  problems  which  influence  the  manufacturers  to 

propose  solutions  which,  in  turn,  guide  the  researchers  in  their 
research  activity.  Periodically  large  user  groups  or 

associations  collect  opinions  on  the  state  of  the  art  and  what 

needs  to  be  done  next.  For  instance.  Guide  Siiare,  CODASYL  DBTG, 
NFS  and  ANSI  iiave  reports  about  DBMS's  [1,13,25]. 
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Since  DBMS  is  a  relatively  new  discipline  many  people  have 
converged  into  it  from  other  areas*  For  instance,  one  can  find 
DBMS  experts  with  backgrounds  in  programming  languages,  operating 
systems,  artificial  intelligence,  theory  of  computing,  etc. 
People  are  still  moving  in.  The  main  reason  for  this 
intellectual  "gold  rush"  is  that  researchers  expect  a  very  high 
return  for  their  investment.  They  feel  that  the  area  is  rather 
unsophisticated,  the  problems  rather  simple  and  the  solutions 
easy  to  come  by.  In  our  opinion,  this  is  no  longer  true.  The 
area  has  developed  a  large  body  of  knowledge  and  a  large  number 
of  published  documents.  Granted,  that  most  of  the  papers  are  not 
worth  reading.  There  are  many  papers,  however,  that  are  very 
important.  Hence,  the  area  is  not  so  easy  to  get  into.  One  can 
point  at  major  contributions  a  few  years  back  which,  in 
retrospect,  are  rather  simple.  At  the  time  they  were  great 
advances.  There  are  still  simple  unimportant  problems  and  hard 
important  problems  to  be  solved.  However,  we  doubt  whether 
anybody  will  find  a  simple  very  important  problem  in  the  future. 
Almost  all  the  simple  important  problems  have  been  solved. 
Hence,  there  is  the  danger  that  we  are  going  to  be  deluged  with  a 
great  number  of  solutions  to  non-existant  problems.  A  problem  is 
non-existant  if  nobody  really  cares  about  its  solution. 

To  illustrate  how  fast  the  area  has  evolved  we  will  outline 
as  examples  two  problem  areas.  They  were  very  important  research 
directions  a  few  years  ago.  However,  we  feel  that  future 
contributions  will  be  evolutionary  rather  than  revolutionary. 


A  few  years  ago  some  DBMS  approaches  and  techniques  were  at 
such  a  rudimentary  stage  that  people  were  building  prototype 
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systems  to  investigate  them  [ 3^38J.  It  will  be  very  hard  to 
surpass  the  efforts  of  the  past  unless  one  has  enough  resources 
to  make  a  prototype  system  realistic  £27],  But  this  implies  an 
organization  and  not  3-5  people  part-time,  A  prototype  system 
which  can  be  built  by  3-5  people  over  2  years  (the  standard 
university  project)  will  probably  be  mainly  educational  and  not 
research  oriented.  Nobody  is  interested  in  ’’here  is  the  way  we 
did  it”  type  of  papers  anymore.  We  know  that  DBMS's  can  be 
built.  To  build  theni  better  and  to  demonstrate  the  advantages 


cannot 

be  done 

an  ymore 

as  a  "shoe  string” 

operation . 

A 

few 

years 

ago  individual 

resea  rche  rs 

made 

major 

contr ibut ions 

in  data 

models  and  data 

languages 

[14], 

Many 

o  thers 

have 

f ol lowed 

suit  and  have  proposed  a  plethora  of 

data 

models 

[291. 

Ho  we ver 

,  we  feel  that 

now  is  a 

time 

for 

consolidation  rather  then  innovation.  People  are  not  interested 
anymore  in  new  data  models  although  they  are  still  interested  in 
results  about  data  models  (which  are  hard  to  come  by).  Most 
”new”  data  models  are,  anyway,  combinations  of  ideas  from  the 
"oldies”.  Coexistence  efforts  are  also  very  important,  e.g,, 
multi-model  data  language  interfaces  [20],  A  "new”  data  model  or 
data  language  with  no  demonstrable  advantages  is  not  a  major 


contribution  acymo 

re. 

In 

the  rest 

of  the  paper  we  outline 

the 

areas  that. 

in  our 

opinion. 

are  still 

worth  investigating. 

We 

expect  the 

major 

research 

resu Its 

to  come  from  these  areas 

The  division 

of  the 

areas  is 

rather 

arbitrary  and  the  names 

may  be  even 

more 

confusing.  However,  we  hope  to  give  a  feeling  of  our  projected 
evolution  of  DBMS  research. 
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2 .  Halti-pgrpose  architectares 

One  of  the  goals  of  DBHS*s  is  to  provide  a  flexible 
interface  to  the  users.  In  this  way  user  prograas  are 
"independent"  froo  the  physical  placeaent  of  the  data.  In 
addition,  it  would  be  nice  if  user  programs  are  "independent" 
from  the  logical  structure  of  the  data.  In  this  way  soae  of  the 
logical  relationships  nay  evolve  while  the  user  only  sees  his  own 
view  of  data.  One  way  of  achieving  this  logical  data 
independence  is  through  a  nultiple  level  architecture.  A 

framework  for  such  an  architecture  has  been  proposed  by 
ANSI/X3/SPAfiC  [ 1 ]•  However,  there  is  still  considerable  debate 
about  some  of  the  features  of  such  an  architecture.  Typical 
questions  that  are  being  asked  are: 

1)  Bhat  i^  the  nature  of  the  conceptual  schema? 

2)  How  will  multiple  model  external  views  be  supported? 

3)  Is  an  ANSI/1L3/SPARC  type  of  architecture  realistic? 

4)  Bhich  of  the  proposed  interfaces  should  be  standarized? 

5}  How  will  integrity  constraints  be  enforced  among  external 
schemata? 

6)  Bill  an  ANSI/X3/SP ARC  type  of  architecture  solve  the 
conversion  problem  by  enabling  DBMS’s  to  evolve? 

In  essence,  the  main  problem  is  the  future  architecture  of 
DBMS’s.  Should  they  provide  more  versatile  and  flexible 
features?  How  should  they  do  it?  The  possibility  of  an  imminent 
standarization  gives  particular  urgency  to  these  problems.  As  a 
byproduct  of  this  effort  much  work  has  already  been  done  on  the 
definition  of  concepts  relating  to  DBMS’s  [1].  Be  do  not  expect 
a  radical  quantum  jump  in  any  direction  in  this  problem  area.  It 
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will  take  some  time  to  reach  any  conclusions.  Experience  in 
software  system  architecture  is  very  important  to  do  any  research 
in  this  area. 


3.  Performance  analysis  and  improvement 

DBMS’s  use  some  standard  mechanisms  to  store  and  access 
data,  e. g.,  files,  inverted  files,  transposed  files,  etc.  The 
organization  of  these  mechanisms  follows  well  known  techniques, 
e.g. ,  B-trees,  binary  trees,  hashing,  etc.  The  problem  comes 
when  data  volumes  get  large.  It  is  not  a  question  of  doing 
something  but  doing  it  well.  An  inefficient  algorithm  or  access 
method  can  severely  limit  a  DBMS’s  performance.  There  is  a  need 
for  requirements  analysis,  modeling,  evaluation,  and  performance 
studies.  Typical  problems  of  this  nature  are: 

1)  Which  secondary  indices  should  be  kept? 

2)  What  mechanism  should  be  used  to  implement  secondary  indices? 

3)  Should  other  access  paths,  separate  from  secondary  indices,  be 
kept  and  how? 

4)  How  can  one  cluster  data  which  is  accessed  as  a  unit? 

5)  Data  encryption  and  compression. 

8)  Hardware  solutions  for  fast  searching. 

7)  Operating  system  tuning  for  DBMS  requirements. 

8)  Performance  indicators  and  measurement. 

9)  Level  of  locking  for  concurrency. 

10)  Proper  utilization  of  different  storage  media. 

11)  Optimal  query  processing. 


The  analytic  models  for  some  of  these  problems  can  become 
quite  complicated.  Experimental  results  are  very  hard  to  come 


8 


by.  It  is  not  easy  to  find  an  available  operational  DBMS  with 
which  to  experiment.  In  addition,  DBMS's  are  sufficiently 
sensitive  that  DBA's  are  very  reluctant  to  let  anybody  "play" 
with  them. 

Distributed  Da^  Bases 

Computer  networks  have  evolved  sufficiently  for  distributed 
DBMS's.  Network  data  transmission  is  fairly  efficient  and 
inexpensive.  In  addition,  there  are  some  data  bases  that  are 
naturally  distributed.  It  is  obvious  that  distributed  data  base 
management  systems  will  be  built  and  operated  successfully  in  the 
future.  Research,  however,  is  lagging  behind  commercial 
development.  There  is  much  research  work  in  network  data 
transmission,  in  file  distribution  in  the  network,  in 
heterogeneous  network  protocols  and  in  large  data  repositories 
for  the  network.  However,  all  of  this  work  is  not  directly 
related  to  distributed  DBMS's.  The  real  proplem  is  to  develop 
techniques  that  provide  data  independence  of  the  user  from  the 
idiosynchracies  of  a  data  base  distributed  in  an  homogeneous 
computer  network.  Some  of  the  associated  problems  are: 

1)  Schema  distribution 

2)  Data  placement 

3)  Message-oriented  system  architecture 

4)  Nature  of  a  transaction  in  a  network 

5)  Enforcing  the  integrity  of  the  distributed  data  base 

6)  Controlled  redundancy 

7)  Concurrent  updates  and  their  meaning. 

8)  Recovery  in  a  distributed  data  base. 
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For  some 
transmiss ion. 
at  the  nature 
bases  it  is 
efficiently, 
control  which 


time  the  emphasis  in  computer  networks  was  on  data 
At  this  point,  it  is  important  to  look  carefully 
of  the  data  being  transmitted.  In  distributed  data 
imperative  to  transmit  data  among  the  nodes 
However,  it  is  also  important  to  have  a  system  wide 
assures  the  correctness  of  the  operation. 


5 .  Data  types 


Programming  language  experts  have  aknowledged  finally  the 
importance  of  data.  Their  answer  in  a  capsule  is:  data  types. 
However,  programming  language  experts  and  DBKS  experts  have 
refused  until  now  to  take  each  other  seriously.  There  are  still 
programming  language  persons  who  believe  that  a  data  base  is 
nothing  more  than  a  ’’complicated"  data  type.  On  the  other  hand, 
some  DBMS  persons  dismiss  data  types  as  "blue  sky  nonsense".  The 
truth  is,  of  course,  somewhere  in  the  middle.  Some  contributions 
on  data  types  are  obviously  important  for  DBMS’s  [24],  On  the 
other  hand,  we  are  very  far  from  an  axiomat izat ion  of  a  data 
base.  There  are  the  differences  between  data  types  and  DBMS 
problems.  The  gap  has  to  be  bridged  and  any  contributions  are 
welcome.  Typical  problem  areas  are: 


1)  Data  types  which  overlap  in  terms  of  data  elements. 


2) 

Formalization  in 

terms 

of 

data 

types  of  some  of 

the  common 

DBMS  structures,  e.g. 

,  DBTG 

set 

type. 

3) 

Lattice  of  data 

types. 

which 

reflect  a  DBMS, 

and  their 

properties, 

4)  Axiom  enforcement  in  the  implementation  of  a  data  type. 

5)  Concurrent  sharing  of  common  elements  of  different  data  types. 
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6)  Feasibility  study  concerning  the  application  of  data  types  in 
the  resolution  of  any  "reasonable"  DBMS  problem. 

It  may  be  that  data  types  can  provide  a  rigorous  framework 
much  needed  in  DBMS's.  However,  it  may  also  be  that  data  types 
are  too  cumbersome  to  use  in  any  meaningful  way.  Time  will  tell. 

6.  Natural  language  interfaces 

For  some  time  there  has  been  a  "rapprochement"  between 
Artificial  Intelligence  and  DBMS's.  The  DBMS  architects  want 
systems  which  provide  casual  user  interfaces  [15].  On  the  other 
hand.  Artificial  Intelligence  persons  want  to  apply  their 
techniques  in  useful  and  realistic  systems  [45].  As  a  first  step 
Question- Answering  systems  are  being  fitted  into  data  base 
applications.  In  addition.  Artificial  Intelligence  models  are 
being  proposed  as  a  solution  to  data  base  semantic  problems  [  35]. 
The  area  is  very  exciting.  It  is  not  exactly  clear  that  DBMS's 
need  natural  language  interfaces.  However,  they  definitely  need 
some  of  the  techniques  used  to  handle  natural  languages.  Any 
model  or  technique  which  can  handle  an  interface  as  complicated 
as  natural  language  can  be  toned  down  to  handle  some  of  the 
mundane  semantics  in  DBMS's.  However,  exchanging  generality  for 
effectiveness  and  efficiency  is  not  always  easy.  Typical 
problems  that  need  investigation  are; 

1)  Semantic  description 

2)  Sophisticated  data  base  dictionaries 

3)  Mapping  semantics  into  DBMS  schemas 

4)  Enforcement  of  semantic  constraints 

5)  Handling  of  free-format  casual  user  interfaces 
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6)  User-DBMS  dialogue 

7)  Building  semantics  in  data  models 

8)  Problem  specification  languages 

9)  Infological  models  [39], 


7 .  Concluding  remarks 


In  the  previous  paragra 
which  need  investigation.  Ou 
It  is  important  to  notice  tha 
team  efforts  between  DBMS  and 
the  correspondence. 


phs  we  mentioned  a  few  a 
r  list  is  by  no  means 
t  all  proposed  areas  are 
an  established  discipli 


reas  in  DBMS 
exhaust ive. 
essentially 
ne.  He  have 


Multi-purpose  architectures 
Performance  improvement 
Distributed  data  bases 
Data  Types 

Natural  Language  interfaces 


DBMS  -  Software  Engineering 
DBMS  -  Performance  Analysis 
DBMS  -  Computer  Networks 
DBMS  -  Programming  Languages 
DBMS  -  Artificial  Intelligence 


Theoretical  problems  have  already  been  investigated  in  the 
associated  areas  we  mention,  e.g,.  Programming  Languages,  etc. 
If  we  extrapolate  from  the  past,  it  seems  that  the  combination 
areas  with  DBMS’s  can  be  fruitful  for  theoretical  study. 
Specifically,  work  on  data  model  properties  like  normal  forms  and 
functional  dependencies  is  very  important  to  derive  proper 
conceptual  schemas  [7].  Queueing  Networks  can  probably  be 
adopted  for  performance  analysis  of  DBMS’s.  General 

synchronization  models  like  Petri  nets,  should  be  relevant  in 
analysis  of  message  networks  of  distributed  data  bases.  Theorem 
proving  techniques  are  relevant  to  abstract  data  types  and  their 
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axioB  specifications.  Finally,  foraal  seaantics  should  be  used 
to  clean  the  data  model  semantics  in  both  AX  and  DBMS's.  It 
seems,  therefore,  that  most  standard  theoretical  areas  can  be 
adopted  to  DBMS  study.  It  will  only  take  an  effort  from  the 
theoreticians  to  understand  the  issues  in  DBMS's. 

tfe  propose  the  following  steps  for  a  potential  researcher  in 

DBMS. 

1)  Bead  a  book  about  DBMS  to  get  the  overall  picture  [ 19,30,43 J. 

2)  Bead  some  of  the  key  classical  papers,  e.g.,  Codd,  Bachman, 
etc. 

3)  Concentrate  in  an  area  where  your  background  will  give  you  the 
necessary  tools.  The  correspondence  table  given  above  should 
help. 

4)  Bead  seven  (7)  papers  in  your  area  of  interest.  Ask  for  a 
recommendation  of  which  papers  to  read. 

5)  THINK 

6)  Try  out  your  results  on  somebody  who  has  a  wide,  and  if 
possible  pragmatic,  experience  in  DBMS's. 

7)  Add  your  gem  to  the  already  unlimited  collection  of  DBMS 
litterature. 
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Abstract 

Abstract  data  types  are  used  to  specify  data  bases  in  a 
potentially  rigorous  manner.  The  notion  of  a  constraint  is 
introduced.  Current  problems  of  data  base  management  systems  are 
expressed  in  terms  of  abstract  data  types  and  are  then  considered 
in  terms  of  data  base  constraints.  Aspects  of  a  theory  of 
constraints  are  defined  and  related  to  the  problems  of  lata  base 
management  systems.  The  main  advantage  of  the  theory  is  that  it 
provides  a  basis  for  the  explicit  use  of  semantics  to  describe 
and  maintain  data  bases. 
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1 •  Introduction 

Solutions  to  some  current  data  base  management  system  (DBMS) 
problems  will  require  rigour  and  formalism  and  also  a  theory 
which  deals  explicitly  with  semantics.  The  formalism  we  require 
may  come  from  the  connection  between  abstract  data  types  and  data 
bases  which  was  the  basis  of  the  1976  SIGPLAN-SIGMO D  Conference 
on  Data.  However,  to  benefit  from  this  relationship  we  must 
overcome  the  problems  which  arise  from  the  complexity  of  data 
bases  and  from  the  different  historical  contexts  of  abstract  data 
types  and  data  bases  (cf.  [  Manola  ],  [Hammer]). 

In  this  paper,  DBMS  problems  are  cast  in  terms  of  abstract 
data  types  in  orde.r  to  formalize  data  base  specification,  DBMS 
problems  arise  from  the  nature  of  a  DBMS,  which  is,  for  some 
limited,  evolving  universe,  a  system  which  presents  each  user 
with  an  abstract  view  and  abstract  operations  over  the  view  which 
are  appropriate  for  each  respective  user.  An  abstract  view  is 
the  collection  of  objects  and  relationships  seen  by  a  given  user 
(class),  ¥e  will  consider  abstract  operations  to  be  the  means  of 
modifying  an  abstract  view,  although  they  may  actually  derive  or 
realize  virtual  parts  of  an  abstract  view.  The  DBMS  must 
maintain  the  view  both  structurally  and  behavioura 1 ly  with 
respect  to  the  universe  it  models.  Four  main  problems  are; 

DB1  specification  and  representation  of  an  appropriate  abstract 
view  for  each  user  in  such  a  way  that  the  views  may  coexist 
without  interference  over  the  same  data  base, 

DB2  verification  that  each  and  every  abstract  view  satisfies 
stated  requirements, 

DB3  implementation  and  enforcement  of  the  properties  of  each 
abstract  view,  and 
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DB4  evolution  of  any  or  all  abstract  views  through  the  altera 
of  view  properties  or  global  data  base  requirements. 

This  paper  suggests  that  the  above  problems  would  ben 
from  the  formalism  presented  by  abstract  data  types  if 
complexity  and  context  issues  were  resolved.  Techniques 
proposed  to  help  resolve  some  of  the  above  issues.  The  notio 
a  data  base  constraint  is  introduced  and  related  to  abstract 
types.  In  conclusion,  constraints  are  presented  as  the  buil 
blocks  of  a  theory  which,  in  allowing  semantics  to  be  dealt 
explicitly,  will  aid  in  the  solution  of  some  important 
prob lems. 
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2  •  Da ta  Bases  in  Terms  of  Abs tract  Data  T^pes 

This  section  describes  a  potentially  rigorous  method  of 
constructing  a  data  base  schema  using  abstract  data  types.  The 
method  is  neither  inherently  top-down  nor  bottom-up;  however,  it 
will  be  described  in  a  top-down  manner.  First,  a  description  of 
the  schema  is  constructed  in  terms  of  objects.  Then,  the  schema 
is  specified  in  terms  of  abstract  data  types.  It  is  assumed  that 
the  data  model/data  language  provide  the  fundamental  domains 
string  and  number.  It  is  assumed  also  that  there  be  an  informal 
description  of  the  data  base  in  terms  of  its  abstract  views 
which,  in  turn,  are  described  in  terms  of  the  objects  and 
relationships  in  the  views.  The  problem  is  to  specify  the 
objects  in  terms  of  the  fundamental  domains.  Figure  2. 1  presents 
a  particular  abstract  view  of  the  course  object  from  a  university 
data  base.  The  view  considers  a  course  to  be  composed  of  objects 
which,  in  turn,  are  composed  from  other  objects.  This  example 
will  be  used  throughout  the  paper. 
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The  procedure  for  constructing  a  schema  is  as  follows; 

Decompose  each  distinct  object  into  its  component  objects 
(e.  g. ,  A  course  has  students,  tutors  and  professors)*  Then, 
decompose  each  component  object  into  components  and  so  forth 
until  the  final  components  are  the  fundamental  domains. 

Keeping  each  object  connected  with  its  component  objects  by 
an  ”is  used  to  compose”-  edge,  we  get  a  forest  of  trees  of 
component  objects.  The  trees  can  be  simplified  by  recognizing 
semantically  similar  (sets  of)  components  (e.g,.  Students, 
professors  and  tutors  have  common  properties  that  pertain  to 
their  being  people),  and  by  representing  them  in  a  single  object 
type  (e.g.,  a  person  data  type).  IS_A  and  PAST_OF  relations 
(Roussopoulos  [1976])  are  useful  in  this  analysis.  Collecting 
like  objects  results  in  a  hierarchy  of  component  objects  which 
may  have  many  roots,  or,  a  network  of  component  objects. 

A  particular  hierarchy  of  objects  presents  only  one  way  of 
viewing  the  objects.  If  students  are  to  be  considered  as  taking 
courses,  another  hierarchy,  rooted  on  student  (Figure  2,2),  can 
be  constructed.  Each  hierarchy  expresses  a  set  of  properties 
that  the  underlying  data  base  must  obey.  We  require  that  no 
hierarchy  express  properties  which  are  inconsistent  with  other 
abstract  views,  A  schema  for  an  abstract  view  is  the  result  of 
combining  all  hierarchies  involving  objects  from  that  abstract 
view.  A  schema  is,  in  general,  a  network  (e.g..  The  edge  from 
student  to  course  in  Figure  2. 1  comes  from  combining  the 
hierarchy  of  Figure  2.2  with  that  of  Figure  2.1  without  the 
edge) ,  Similarly,  a  data  base  schema  description  may  be 
constructed  from  the  abstract  view  schema  descriptions. 
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data  type  contains  a  list  of  student  pointers) ,  The  existence  of 
a  cycle  in  a  network  of  componant  objects  indicates  that  the 
associated  abstract  data  types  will  require  pointers. 

Unlike  the  programming  language  treatment  of  abstract  data 
types  (e.g.,  [Wulf]),  an  instantiation  of  an  abstract  data  type, 
as  used  here,  has  almost  no  local  data.  In  data  bases,  data 
values  are  shared  and  views  are  not  neccessarily  shared.  A  data 
value  for  an  instantiation  of  an  abstract  data  type  resides  in 
the  data  base.  Such  a  data  value  is  an  appropriate  bit  pattern 
for  the  representation  of  the  abstract  data  type. 

Using  the  above  construction,  we  can  view  a  data  base  as  a 
set  of  data  values  which  are  interpreted  by  a  network  of  abstract 
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claim  that  a  data  base  is 
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may  lead  abstract  data  type  people  to 
just  a  complicated  abstract  data  type. 
The  emphasis  here  should  be  on  "complicated".  Data  bases  are  so 
complex  and  abstract  data  types  are  so  precise  that  it  may  appear 
that  the  result  of  using  abstract  data  type  specifications  to 
describe  data  bases  is  overly  complicated.  This  view  can  appear 
to  be  so  full  of  detail  that  the  benefit  of  abstract  data  types 
may  be  lost  for  DBMS  problems.  As  do  data  type  people,  we  would 
like  to  use  abstract  data  types  to  simplify  data  definitions. 


3 .  Casting  DBMS  Problems  in  Terms  of  Abstract  Data  Types 

The  problem  of  abstraction,  representation,  and  coexistence 
of  abstract  views  must  deal  with  different  users  requiring 
different  structural  and  behavioural  views  of  the  same  data.  »e 
need  a  method  for  specifying  these  views.  The  coexistence  of 
views  without  interference  has  been  addressed  by  the  three  schema 
approach  of  the  [  A  NS I/X3/S PARC  ]  proposal.  In  general, 
construction  and  coexistence  of  views  is  the  problem  of  choosing 
an  appropiate  data  raodel/data  language.  In  terms  of  abstract 
data  types,  we  need  a  structured  method  for  specifying  abstract 
data  types  in  a  complex  network  of  the  type  described  above.  We 
also  need  a  set  of  abstract  data  types  corresponding  to  the 
logical  data  structures  of  the  data  model/data  language  being 
used.  If  we  realize  that  only  a  few  generic  concepts  are  needed 
to  describe  a  data  base,  we  can  reduce  the  complexity  of  the 
network  by  using  a  small  set  of  'generic*  abstract  data  types 
(e. g. ,  type  generators  or  the  parameterized  types  of  [Johnson  and 
Morris])  for  which  a  variety  of  specific  properties  can  be 
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specified  (Generic  functional  relations,  domains,  and  record 
types  are  given  in  section  5). 

The  first  DBMS  problem,  DPI,  is  expressed  in  terms  of 
abstract  data  types: 

ADT1.1  Generate  generic  abstract  data  types  which  can  be  used  to 
describe  the  objects  of  any  data  model. 

In  addition  to  generic  abstract  data  types,  subsetting  and 
combining  of  networks  may  aid  the  problem  of  coexistence: 

ADT1.2  Determine  methods  for  decomposing  objects,  collecting 
semantically  similar  objects  and  combining  hierarchies  of 
objects  in  order  to  reduce  the  complexity  of  constructing 
individual  hierarchies  of  abstract  data  types  which  will 
coexist  in  a  network  of  abstract  data  types  without 
interference  over  the  same  data  values. 

The  second  problem  is  the  verification  that  the  schema  is 
self-consistent  and  meets  some  stated  requirements.  Currently, 
schema  verification  is  limited  by  the  details  expressed  in  data 
definition  languages.  Further  verifi cation  may  be  done  through 
user  coded  programs.  These  methods  are  incomplete  and  ad  hoc. 
However,  suppose  that  users  were  to  specify,  independently  and  in 
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The  second  DB’^S  problem  is  stated  in  terms  of  abstract  data 
types: 

ADT2  Ensure  that  there  are  no  conflicting  stuctural  or 
behavioural  properties  in  a  network  of  abstract  data  types. 
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Properties  that  may  conflict  froa  one  abstract  view  to 
another  are:  range,  format,  units  and  ordering  specifications. 
An  example  of  a  logical  conflict  is  that  one  abstract  view  raay 
permit  one  or  more  professors  to  be  associated  with  a  given 
coarse  while  another  view  requires  that  exactly  one  professor 
teach  a  course. 

The  third  problem  concerns  the  implementation  and 
enforcement  of  abstract  views  as  expressed  in  behavioural  and 
structural  properties  and  in  semantic  integrity  constraints.  In 
terms  of  abstract  data  types,  we  must  implement  properties  of 
abstract  data  types  directly  in  one  abstract  data  type  or 
indirectly  by  ensuring  that  the  effect  of  the  property  propagates 
through  the  part  of  the  network  affected  by  the  abstract  data 
type  (i.e.,  the  scope  of  the  abstract  data  type  property.  e.g.. 
If  the  employee  data  type  is  altered,  the  professor  and  tutor 
data  types  alter  accordingly  since  they  are  based  on  the  employee 
data  type).  For  implementation  or  enforcement  reasons,  we  may 
wish  to  transform  a  property  of  an  abstract  data  type  into  a 
property  of  an  underlying  abstract  data  type.  We  now  express  the 
third  DBMS  problem  in  terms  of  abstract  data  types: 

ADT3  Be  able  to  transform  local  properties  of  abstract  data  types 
into  equivalent  and  appropriate  properties  elsewhere  in  the 
network. 

For  example,  assuming  that  each  abstract  view  reguire 
students  to  be  ordered  in  a  different  way  (e.g.,  by  name,  by 
number,  by  course,  by  fees  owed) ,  consider  the  relationship 
between  the  abstract  data  type  and  the  stored  data, 
the  ordering  properties  be  enforced? 


Where  can 
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The  last  problem  is  that  of  evolution  through  data 
independence.  A  major  achievement  of  abstract  data  types  is  a 
form  of  logical  data  independence  which  allows  programs  to  relate 
on  a  logical  plane  by  suppressing  unnecessary  details  of 
structure  and  storage.  DBMSes  require  an  additional  form  of 
logical  data  independence  which  is  the  ability  to  have  that 
logical  plane  evolve  according  to  user  needs  and  in 
correspondence  with  the  universe  it  models.  In  terms  of  abstract 
data  types,  this  may  require  the  introduction,  to  the  network,  of 
new  abstract  data  types  according  to  new  requirements  or  simply 
to  effect  the  alteration  of  an  existing  abstract  data  type.  One 
example  of  a  change  is  the  addition  or  alteration  of  a  semantic 
integrity  constraint  (e.g.,  A  course  may  have  one  tutor  for  every 
20,  rather  than  for  every  25,  enrolled  students).  It  is  obvious 
that  local  changes  may  alter  the  network,  but,  we  do  not  want  to 
cause  inconsistencies.  This  last  DBMS  problem  stated  in  terms  of 
abstract  data  types  is: 

ADT4  Be  able  to  make  local  changes  in  the  network  without  creating 

•problems*  for  other  abstract  data  types. 

The  advantages  of  a  network  of  abstract  data  types  used  to 
describe  a  data  base  relate  to:  a  methodology  for  data  base 
design,  the  network  structure,  the  previously  established  results 
for  abstract  data  types,  and  the  potentially  uniform  and  rigorous 
specifications  provided  by  abstract  data  type  specification 
techniques.  The  design  methodology  is  similar  to  that  of  [Smith 
and  Smith].  It  allows  a  designer  to  consider,  individually,  the 
structural  and  behavioural  properties  of  objects  in  abstract 
views  which  are  combined  to  form  a  schema.  The  advantages  of 
abstract  data  types  relating  to  precise  description  and  to 


28 


software  validation  have  been  described  elsewhere  [Gattag; 
Guttag,  Horowitz  and  Musser]. 

As  described  in  the  next  section,  a  data  base  roust  be  shown 
to  satisfy  stated  reguiremen ts.  The  requireroents  must  be  stated 
in  a  precise  and  uniform  manner.  The  advantages  of  such  a 
description  are  indicated  in  the  next  section. 

4 .  Constraints 

Let  us  consider  the  abstract  data  type  problems  in  terms  of 
their  properties  and  their  data  values. 

We  assume  that  the  properties  of  the  data  base  are  given  in 
some  data  base  specification.  The  data  model/data  language 
provides  a  data  definition  language  with  which  to  describe  some 
of  those  properties  (e.g, ,  the  structural  properties  of  abstract 
data  types).  For  a  relational  DBMS,  these  properties  correspond 
to  the  domain  definitions  and  the  relational  structure  properties 
of  f Hammer  and  McLeod].  Such  declarative  expressions  of 
properties  are  more  amenable  to  comparison  and  analysis  than  are 
procedura 1  enforcements  (e.g.,  triggers,  on  conditions,  check 
clauses,  and  data  manipulation  programs),  hence,  we  are  concerned 
with  declarative  expressions  of  data  base  properties.  We  will 
call  those  properties  that  cannot  be  expressed  in  the  data 
definition  semantic_  integrity  No  student  in  CSC100 
may  receive  a  grade  of  A).  These  properties  correspond  to  the 
relation  constraints  of  [Hammer  and  McLeod]. 

A  data  base  constraint  is  an  expression  of  a  semantic 
integrity  rule  in  the  form  of  an  assertion  over  data  values.  A 
constraint  asserts  that  a  (set  of)  data  value (s)  exhibits  a  given 
property  or  obeys  a  given  relation  with  respect  to  other  data 
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values.  Whan  associated  with  a  specific  set  of  data  values,  a 
constraint  evaluates  to  true  or  false  (e.g..  The  assertion  that 
every  full-time  student  take  at  least  four  and  at  most  six 
courses  is  true  or  false  for  each  student  in  the  data  base) . 

A  constraint  is  expressed  in  terms  of  the  objects  in  a 
schema.  A  particular  abstract  data  type  may  have  a  set  of 
constraints  over  it  asserting  the  existence  of  properties  and 
relations  over  its  potential  data  values  {e.g.,  A  student  number 
must  obey  a  given  format  and  be  within  a  given  range  depending  on 
the  student's  status).  Similarly,  a  network  of  abstract  data 
types  has  an  associated  constraint  set  asserting  the  existence  of 
required  properties  (e.q. ,  A  tutor  must  be  a  student  who  has 
received  at  least  a  B+  for  the  course  being  tutored.  There  may 
be  one  tutor  for  every  25  students  enrolled  in  the  course). 

A  data  base  inf  tat  ion  is  a  (sub)  schema  and  its 

constraint  set  with  an  associated  set  of  values.  A  wodel  for  a 
(sub) schema  is  a  data  base  interpretation  for  which  the  data 
values  satisfy  the  constraints,  A  set  of  constraints  over  a 
(sub) schema  is  satisfiable  if  it  has  a  non-empty  set  of  models. 

The  following  definitions  concern  changes  made  to  a 
constraint  set  C,  by  adding  [deleting]  a  constraint  c.  With 
respect  to  the  constraint  set  C,  the  constraint  c  is: 
redundant  if  the  set  of  models  for  C  is  the  same  as  for  C+c  [C-c], 
satisfiable  if  there  are  some  models  for  C+c  [C-c], 
contradictory  if  there  are  no  models  for  C+c, 

S-O^^istent  if  a  model  for  C  +  c  [C-c]  is  not  invalid  as  a  model 


for  C 
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Now,  we  give  a  definition  for  the  equivalence  of  sets  of 
constraints.  Consider  some  subset  A  of  a  set  of  constraints  C. 
A  distinct  set  of  constraints  B: 

implies  A  if  by  substituting  B  for  A  in  C  we  get  at  most  the 
same  set  of  models,  (i.e.,  the  set  of  models  for  C 
contains  the  set  for  C-A+B). 

is  e  qui valent  to  A  iff  B  implies  A  and  A  implies  B  in  which  case 
A  and  B  are  mutually  redundant. 

A  definition  for  (equivalence  leads  us  to  equivalence¬ 
preserving  transformations  that  will  allow  us  to  substitute  a 
more  desirable  set  of  constraints  B  for  a  set  A  within  a  set  of 
constraints  C,  Transformations  are: 

exact  if  B  is  equivalent  to  A  (i.e,,  the  same  models  for  C-A+3  as 
for  C)  . 

strong  if  B  implies  A  {i.e.,  fewer  models  for  C-A+B  than  for  C) , 
weak  if  A  implies  B  (i.e,,  more  models  for  C-A+B  than  for  C), 

B.  Casting  ADT  Problems  in  terms  of  Constraints 

Let  us  consider  the  abstract  data  type  problems  of  section  3 
in  terms  of  constraints  over  abstract  data  types. 

In  order  to  generate  generic  abstract  data  types  which  may 
be  used  to  describe  the  objects  of  any  data  model,  we  must 
determine  the  generic  properties  that  must  be  represented.  This 
process  is  not  unlike  the  collecting  of  semantically  similar 
abstract  data  types  when  constructing  a  schema,  as  described 
above.  Since  a  constraint  is  an  assertion  of  the  existence  of  a 
property,  we  are  interested  in  generic  constraints  over  the 
generic  abstract  data  types.  Let  us  consider  some  candidates  for 
generic  constraints. 
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Functionality  is  a  property  essential  to  roost  data  models. 
Functional  dependencies  are  important  not  only  for  the  relational 
model  but  also  for  any  data  model  irhich  benefits  from  the 
normalization  of  record-like  structures.  Child-parent 
functionality  is  a  definitive  property  of  the  hierarchic  data 
model  while  network  models  use  a  member-owner  functionality  as 
seen  in  the  CODASYL  "set”. 

The  notion  of  domain  is  common  to  all  data  models.  A 
relation  -  the  central  concept  of  the  relational  model  -  is  a 
subset  of  a  cartesian  product  of  domains.  Similarly,  most  other 
models  compose  higher  level  structures  using  domains.  For 
example,  CODASYL  composes  data  aggregates  and  record  types  from 
data  items;  IMS  constructs  segment  types  from  data  elements  and 
IDS  uses  data  fields  to  construct  records.  Clearly,  the  higher 
level  structures  (e.g.,  relations,  record  and  segment  types)  are 
different  flavours  of  the  same  generic  concept  which  embodies  the 
common  properties.  Variations  such  as  the  existence  of  a 
repeating  group  could  be  accommodated  by  the  parameters  of  a 
generic  "record”  abstract  data  type. 

Constraints  may  assert  the  existence  of  behavioural 
properties  in  terms  of  the  pre-  and  post-conditions  required  for 
the  execution  of  the  related  operations.  The  above  properties 
are  candidates  for  generic  structural  properties  of  abstract  data 
types.  Let  us  consider  behavioural  properties  which  are  generic. 
A  fundamental  requirement  of  a  data  model  is  the  ability  to 
relate  data  objects.  This  facility  is  provided  by  the  join  and 
other  relational  algebra  operations  in  the  relational  model;  by 
qualified  navigation  commands  in  the  network  model  and  by 
qualified  tree  traversal  operations  in  the  hierarchic  model,  A 
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set  of  behavioural  properties  common  to  all  data  models  is  the 


ability  to  query,  update,  insert,  and  delete  a  data  value. 

He  now  state  the  problem  concerning  genereric  abstract  data 
types,  ADT1,1,  in  terms  of  constraints: 

C1.1  Obtain  a  complete  set  of  generic  constraints, 
k  set  of  generic  constraints  is  complete  if  the  constraints  are 
sufficient  to  assert  the  existence  of  the  structural,  behavioural 
and  other  integrity  constraints  of  a  given  data  model. 

The  second  part  of  the  problem  relating  to  generic  abstract 
data  types,  ADT1.2,  can  be  stated  as: 

Cl. 2  Determine  how  constraints  can  be  collected  and  parameterized 
so  as  to  produce  a  small  complete  set  of  generic 
c  onstrain  ts. 

The  answers  to  these  problems  provide  some  of  the  properties 
required  for  the  external  and  conceptual  schemata  proposed  by 
[ ANSI/X3/SP ARC  ],  or  more  generally,  those  required  for  the 


construction  and 
The  second 
consistency  of  a 
the  constraints  o 
C2  Prove  that 
satisfied  by  a 
The  third 
transform  local  a 
restrictions  som 
Each  abstract  dat 
given  set  of 


coexistence  of  abstract  views. 

abstract  data  type  problem  concerning  the  self¬ 
network  can  be  expressed  directly  in  terms  of 
ver  the  network. 

a  given  set  of  constraints  is  satisfiable,  or, 
given  data  base. 

abstract  data  type  problem  requires  that  we 
bstract  data  type  properties  into  appropriate 
ewhere  in  the  network  of  abstract  data  types, 
a  type  must  be  implemented  so  as  to  ensure  a 
properties  which  are  stated  as  constraints. 


Considering  the  cost  of  implementation  and  enforcement  against 
that  of  flexibility,  we  may  wish  to  place  properties,  expressed 
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as  constraints,  in  different  parts  of  the  network  (e.g,.  That 
every  student  in  CSClOO  must  not  receive  an  A  may  be  enforced  in 
either  the  student  instantiation  or  the  instantiation  for 
CSClOO).  This  abstract  data  type  problem  is  related  to 
constraints  in  two  parts: 

C3. 1  Given  a  set  of  constraints  produce  an  equivalent  set,  and 
C3.2  Find  exact  (strong,  weak)  transformation  rules  for 

constraints  so  that  one  constraint  set  may  be  replaced  by  an 
equivalent  set. 

Exact  transformation  rules  may  be  difficult  to  achieve, 
however,  the  easier  strong  and  weak  rules  are  very  useful.  A 
strong  transformation  rule  will  allow  us  to  replace  one  set  of 
constraints  with  a  set  which  is  at  least  as  strong.  A  weak 
transformation  rule  will  ensure  that  the  new  constraint  set  is  no 
stronger  than  the  original  set. 

The  final  problem  of  data  independence  requires  that  we  make 
local  changes  to  an  abstract  data  type  without  creating  conflicts 


with  others. 

These  problems 

may  be 

detected 

by  applying 

constrain  ts. 

This  leads  us  to  a 

set  of 

problems 

involving  a 

constraint  c 

which  is  added 

to  [deleted  from] 

a  satisfiable 

constraint  set  C: 

C4,  1  Prove  that  C  +  c  [C-c]  is  satisfiable, 

C4.2  Prove  that  c  is  satisfied  by  a  given  model  for  C, 

C4.3  Prove  that  a  given  non-empty  model  set  for  C  is  equivalent 
to  (contained  in,  contains)  the  model  set  for  C+c  [C-c], 

C4,4  Prove  that  c  is  redundant  with  respect  to  C,  and 
C4.5  Find  a  minimal  constraint  set  for  C. 

If  we  can  say  something  about  generic  constraints,  the 
satisfiability,  equivalence  and  transformation  of  constraints  and 
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tlie  alteration  of  a  constraint  within  a  set  then  we  have  a 
fraaework,  a  theory  of  constraints.  He  believe  that  this  theory 
will  allow  us  to  express  some  fundamental  DBMS  problems. 


6 .  Conclusions 

We  have  suggested  how  abstract  data  types  could  be  used  to 
specify  data  bases  in  a  potentially  rigorous  and  uniform  way.  We 
have  used  these  ideas  to  express  some  current  DBMS  problems  in 
terms  of  abstract  data  types.  We  have  considered  abstract  data 
type  problems  in  terms  of  data  base  constraints.  Some  aspects  of 
a  theory  of  constraints  have  been  introduced.  The  relevance  of 
the  theory  to  data  base  problems  is  suggested  by  the  casting  of 
those  problems  in  terms  of  constraints.  The  main  advantage  of 
the  theory  is  to  permit  semantics  to  be  dealt  with  explicitly 
through  constraints, 
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(PARTIAL)  COURSE  ABSTRACT  VIEW 


a  data  base  object 


Y  is  used  to  compose  X 


''k  /  :  indicate  additions  to  Figure  2.1  from  Figure  2.2 
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An  Example  of  ANSI^SP ABC  Architecture 

by 

D.  Tsichritzis  and  A.  Klug 

Computer  Systems  Research  Group 
University  of  Toronto 


Abstract 

The  ANSI/SPABC  framework  is  becoming  accepted  as  a  guideline 
for  development  of  future  Data  Base  Management  Systems,  In  this 
paper  an  example  architecture  is  outlined  which  follows  the 
ANSI/SPARC  framework.  Features  for  the  conceptual  model  are 
proposed.  Three  external  models  corresponding  to  the 
hierarchical,  network  and  relational  approach  are  mapped  onto  the 
conceptual  model.  The  facilities  of  the  internal  model  are 
outlined  and  shown  to  support  the  conceptual  model.  This 
architecture  is  being  followed  in  a  system  currently  under 
development  at  the  University  of  Toronto. 
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1 .  INTRODUCTION 


The  framework  proposed  by  ANSI/SPAEC  is  becDming 
increasingly  accepted  as  a  guideline  for  the  future  development 
of  Data  Base  Management  Systems  (DBMS’s)  [1].  The  distinction 
between  the  external^  conceptual  and  internal  schemas  is  one  of 
the  central  ideas  in  the  proposed  framework.  This  separation  is 
very  important  for  many  reasons. 

1)  Logical  data  independence  of  the  user  from  the  schema  is  an 
important  requirement  for  future  DBMS's.  The  ANSI/SPARC 
framework  provides  logical  data  independence  by  its  separation  of 
external  and  conceptual  schemas.  Physical  data  independence  is 
also  provided  by  the  separation  of  conceptual  and  internal 
schemas. 

2)  Data  models  are  conceptual  tools.  Users  should  not  be  forced 
to  visualize  their  data  in  only  one  way.  The  ANSI/SPARC  external 
schemas  provide  many  different  views  of  data  according  to  one  or 
several  data  models. 

3)  The  investment  of  both  manufacturers  and  users  in  current 
systems  is  so  large  that  these  systems  will  probably  evolve 
rather  than  be  revolutionized.  Future  systems  will  have  to 
support  the  traditional  approaches  as  well  as  new  approaches.  A 
single  DBMS  may  have  to  support  many  approaches.  The  external 
schema  facility  provides  an  environment  for  handling  this 


requirement 
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4)  To  aid  data  base  design  and  development  by  the  DBA  a  common 
denominator  for  all  existing  views  of  data  is  needed.  This 
facility  is  provided  by  the  conceptual  schema. 

5)  To  assist  data  base  tuning  as  users'  requirements  change  a 
great  amount  of  flexibility  in  terms  of  physical  structures  and 
access  paths  is  needed.  This  environment  is  provided  by  the 
internal  schema  facility. 

The  ANSI/SPARC  proposal  discusses  the  different  modules  and 
interfaces  in  rather  general  terms.  The  generality  is  important 
to  accommodate  different  ideas.  However,  it  is  very  hard  to 
focus  and  discuss  some  very  difficult  questions  without  being 
more  specific.  More  detailed  architectures  should  be  proposed 
that  will  lead  to  debate  on  specific  issues.  In  this  way  the 
future  development  of  DBMS's  will  be  influenced. 

In  this  paper  we  outline  an  example  of  an  ANSI/SPARC 
architecture  being  developed  at  the  University  of  Toronto.  Our 
proposal  is  centered  around  the  conceptual  model.  The  external 
models  depend  very  much  on  the  applications  for  which  they  are 
used.  The  internal  model  depends  heavily  on  hardware  and 
Operating  System  architecture.  However,  it  is  very  hard  to 
evaluate  a  conceptual  model  proposal  in  isolation.  For  this 
reason  we  also  outline  the  external  and  internal  models  and  the 
associated  interfaces. 

2.  CONCEPTUAL  LEVEL 

Many  different  data  models  have  been  proposed  for  DBMS's. 
However,  only  three  have  gained  widespread  acceptance,  i.e. 
hierarchical,  network  and  relational.  While  all  of  them  will 
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probably  have  to  be  supported  at  the  external  schema  level,  is 
any  one  of  them  appropriate  for  the  conceptual  level? 


The  hierarchical  data  model  does  not  permit  enough 
flexibility  for  a  conceptual  model.  Data  can  only  be  organized 
according  to  trees.  Often  a  more  general  organization  is 
required,  e.g.,  multiple  links  between  the  same  two  record  types. 
Such  relationships  can  only  be  represented  in  a  clumsy  way  in  the 
hierarchical  data  model. 


The  network  approach  as  exemplified  by  the  CODASYL  DBTG 
proposal  provides  more  flexibility.  However,  it  still  retains 
some  restri.c tions.  For  example,  it  does  not  allow  DBTG  sets 
having  the  same  record  type  for  owner  and  member.  General  N;M 
relationships  cannot  be  represented  directly.  Furthermore,  the 
DBTG  proposal  contains  many  features  which  are  internal  schema 
oriented,  e.g.,  LOCATION  MODE. 


The  relational  data  model  was  originally  proposed  for  the 
casual  user.  However,  the  conceptual  schema  user  is  not  a  casual 
user.  He  wants  to  exercise  a  certain  amount  of  control  in  the 
use  of  the  data  base.  The  relational  approach  in  its  pure  form 
offers  too  much  flexibility  and  generality  which  make  effective 
control  hard  to  impose.  For  instance,  the  ability  to  form 
arbitrary  joins  dynamically  can  be  dangerous  if  proper  attention 
is  not  paid  to  their  semantics.  Relational  closure  may  not  be 
needed.  In  addition,  duplicates  and  some  form  of  order  and 
currency  are  needed  at  the  conceptual  level  to  support  navigation 
at  the  external  schema  level.  It  should  be  pointed  out  that  some 
relational  systems  do  not  follow  exactly  the  relational  model. 
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For  instance,  system  R  is  not  a  pure  relational  language  [2], 
For  example,  ordering  and  cursors  have  been  introduced. 

Each  of  the  approaches  is  not  exactly  appropriate  for  the 
conceptual  model.  We  propose,  therefore,  as  a  compromise  a 
general  network  data  model  consisting  of  record  types  connected 
iiliJSS.  Record  types  are  similar  to  DBTG  record  types  without 
some  of  the  intricate  internal  schema  oriented  options,  e.g., 
RG*s,  vectors,  aggregates,  etc.  A  record  type  consists  of 
different  attributes.  Record  types  can  be  viewed  as  normalized 
relations.  However,  they  have  a  certain  order  and  duplicates  are 
allowed.  A  record  type  key  is  similar  but  not  identical  to  a 
relation  candidate  key.  It  uniquely  identifies  a  record 
occurrence.  However,  it  does  not  imply  any  access  mechanism  like 
the  CODASYL  data  base  key. 

Links  are  general  N: M  connections  among  pairs  of  record 
types.  We  do  not  allow  information  bearing  connections.  All 
links  are  defined  as  non- info rmation  bearing  according  to  a 
closed  property  (predicate)  among  the  attributes  of  the  record 
types  involved.  No  manual  membership  is  allowed.  We  restrict 
our  attention  to  binary  links  between  any  two  record  types. 
Links  can  be  loops  connecting  a  record  type  with  itself.  All 
links  are  named  explicitly.  Links  are  similar  to  named  joins 
between  relations.  We  can  specify  restrictions  or  intentions  as 
integrity  constraints  for  the  links,  e.g.,  functional  (1:N), 
total,  ,  etc.  In  figure  I  we  outline  as  an  example  a  conceptual 
schema  diagram  of  record  types  and  links.  The  example  is  similar 
to  Date's  with  the  addition  of  some  links  to  illustrate 
additional  features,  e.g.,  looping  links,  N:M  links.  [3]. 
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Notice  that  an  N:M  connection  has  to  be  incorporated 
sometimes  by  using  two  1:N  links  and  an  additional  record  type. 
For  instance,  we  may  want  to  encode  some  additional  data  in  the 
record  type,  e.g.  ENROLMENT. GRADE.  In  other  cases  the  additional 
record  type  may  be  necessary  because  we  cannot  easily  express  a 
linking  property  as  a  closed  formula.  We  have  therefore  to 
incorporate  it  as  a  record  type,  e.g.,  TEACHING  record  type 
between  OFFERING  and  EMPLOYEE. 

In  addition  to  record  types  and  links  we  have  the  facility 
to  define  selectors  in  the  conceptual  schema.  A  selector  is  a 
named  subset  of  the  record  occurrences  of  a  given  record  type.  A 
selector  is  defined  using  some  qualification  of  the  attributes  of 
the  record  type.  Selectors  are  similar  to  ISA  hierarchies  in 
Artificial  Intelligence.  They  are  important  both  for  mnemonic 
and  semantic  reasons.  For  instance,  the  EMPLOYEES  where 
ABDRESS=P ARIS  may  be  a  significant  subset  of  the  EMPLOYEE  record 
type  and  can  be  defined  as  a  selector  PARIS_EMP  as  in  figure  I. 

We  also  provide  a  DML  at  the  conceptual  level.  An  important 
feature  for  this  DML  is  the  notion  of  a  selection  variable.  A 
selection  variable  represents  a  set  of  record  occurrences  of  a 
given  record  type  [5].  Selection  variables  allow  set-of- records- 
at-a-time  navigation  through  the  data  base.  At  any  point  of  time 
the  value  of  a  selection  variable  is  an  ordered  set  of  record 
occurrences  of  the  same  type.  Each  selection  variable  is 
declared  as  associated  with  a  given  record  type.  It  can  then  be 
assigned  values  by  selection  on  a  given  record  type  using  Boolean 
qualification  of  where  clauses.  The  assignment  may  include 
selectors  and  values  of  other  selection  variables  of  the  same 
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type.  A  selection  variable  can  also  be  assigned  values  using  the 
contents  of  a  given  selection  variable (s)  following  a  link  to  a 
record  type  or  a  chain  of  links.  This  facility  is  similar  to  LSI 
expressions  [5]. 

Individual  occurrences  of  records  represented  by  a  selection 
variable  are  obtained  using  GET  FIEST/LAST  and  GET  NEXT/PRIOR 
commands.  A  currency  indicator  is  associated  with  every 
selection  variable  which  marks  the  current  record  of  the 
selection  variable. 

The  DML  also  has  the  concept  of  virtual  record.  A  virtual 
record  type  is  a  join  along  a  chain  of  links  and  selectors 
followed  by  a  projection  of  a  set  of  attributes.  It  corresponds 
to  a  defined  relation  in  LSL  [5].  Virtual  record  types  are 
mainly  used  to  support  the  external  relational  model  operations. 

The  exact  syntax  of  the  conceptual  model’s  DML  will  not  be 
listed.  As  with  the  DDL,  we  will  illustrate  the  DML  with 
examples  in  the  following  section. 

3.  EXTERNAL  LEVEL  AND  EXTERNAL/CONCEPTUAL  MAPPINGS 

To  illustrate  the  support  of  the  three  models  (relational, 
network,  hierarchical)  at  the  external  level  we  will  use  as 
example  the  three  models  as  supported  by  EDBS  [4].  The  choice  of 
EDBS  was  made  without  loss  of  generality.  The  EDBS  languages  are 
simple,  well  defined  and  represent  fairly  well  the  three 
approaches. 

We  will  briefly  discuss  how  features  of  the  external  models 
are  supported  at  the  conceptual  level  and  we  will  illustrate  this 
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support  with  some  examples.  All  examples  implement  the  queryt 
"Find  the  names  of  all  students  who  received  an  A  in  a  Stockholm 
course  offering". 

The  relational  language  is  ALPHA-like.  Target  lists  in  EDBS 
are  restricted  to  one  or  two  relations.  However,  the  conceptual 
model  could  easily  support  more  complicated  target  lists.  Where 
clauses  are  translated  to  combinations  of  selection  clauses  and 
link  expressions  at  the  conceptual  level.  The  example  guery 
expressed  in  the  relational  model  and  its  conceptual  translation 
is  presented  in  figure  II. 

Parent/child  relationships  in  the  hierarchical  model  are 
mapped  to  links  which  are  functional  and  total  and  which  are 
defined  by  matching  the  key  of  the  parent  conceptual  record  with 
an  item(s)  of  the  child  conceptual  record.  The  matched  part  of 
the  child  record  does  not  appear  at  the  external  level. 

The  hierarchical  language  is  similar  to  DL/1  of  IMS.  To 
support  a  tree  traversal  of  the  database  at  the  conceptual  level, 
selection  variables  are  defined  for  each  segment  on  the  record 
type  holding  that  segment’s  key.  Except  for  the  root  segment, 
each  selection  variable  holds  the  children  of  the  current  of  the 
parent  selection  variable.  The  data  base  position  pointer  and 
the  pointer-to-parent  are  then  simulated  by  selection  variable 
names.  With  this  scheme  a  typical  hierarchical  command  such  as 
GET  NEXT  will  be  translated  to  different  sequences  of  conceptual 
level  commands  depending  on  the  state  of  the  selection  variables, 
e.g.,  some  currency  indicators  may  need  to  be  moved  forward  while 
other  selection  variables  may  need  to  be  refilled  entirely.  The 
example  query  in  hierarchical  terms  is  given  in  figure  III.  Note 


46 

that  in  this  example  external  status  values  are  not  represented 
at  the  conceptual  level. 

With  the  network  external  model  each  record  type  has  a 
currency  indicator  which  is  directly  supported  at  the  conceptual 
level  by  conceptual  record  currency  indicators.  Sets  in  the  EDBS 
network  model  are  all  manual  and  information  bearing.  They  are 
mapped  at  the  conceptual  level  to  functional  links  mapping  keys 
to  items  as  with  the  hierarchical  model.  The  current  of  a  set  is 
represented  by  two  selection  variables,  one  holding  the  set  owner 
and  the  other  holding  the  set  members.  The  example  query  is 
expressed  in  the  network  language  in  figure  IV. 

For  each  of  the  three  external  schemas  we  need  an  External 
Schema/Conceptual  Schema  mapping.  We  have  left  them  implicit  for 
space  reasons.  In  this  example  they  can  be  inferred  by  the 
correspondance  of  conceptual  and  external  names. 

a*  Internal  Level 

It  is  very  hard  to  give  a  concrete  proposal  for  the  internal 
model.  There  is  a  great  variety  of  different  mechanisms  which 
can  be  used  at  this  level.  Each  one  has  distinct  advantages  in 
some  situations.  Their  performance  depends  on  the  properties  of 
the  generated  data  base,  the  relative  frequency  of  operations, 
characteristics  of  the  supporting  operating  system  and 
idiosynchracies  of  the  hardware.  It  is  rather  simple  to  come  up 
with  a  ‘'complete"  set  of  mechanisms.  Namely,  there  are  very  few 
tools  which  are  needed  at  least  conceptually.  However,  the 
internal  model  is  performance  oriented.  It  is  important  to  have 
a  sufficient  variety  of  mechanisms  to  ensure  adequate  performance 
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in  most  situations.  To  decide  exactly  how  many  and  what  kind  of 
mechanisms  to  incorporate  is  a  hard  DBMS  design  decision.  To 
decide  how  to  exploit  the  mechanisms  in  a  given  situation  is  a 
hard  DBA  decision. 

The  CODASYL  DBTG  proposal  is  a  very  good  example  for  the 
number  of  options  which  may  be  necessary  at  the  internal  level. 
Many  of  DBTG  options  are  designed  to  correspond  to  essentially 
different  implementation  mechanisms.  These  mechanisms  have 
distinct  advantages  for  certain  operations.  It  is  a  historical 
accident  that  DBTG  will  have  to  be  supported  at  the  external 
level  although  its  features  are  mainly  internal  level  oriented. 

We  base  our  internal  schema  on  the  following  proposal  which 
is  somewhat  restrictive.  Its  main  advantage  is  the  ease  of 
implementation  in  our  environment.  We  allow  only  files  and 
indices  as  building  blocks  of  the  internal  schema.  Internal 
schema  files  are  usual  files  with  fixed  size  records.  Records 
are  stored  sequentially  according  to  insertion.  Deleted  records 
are  marked.  Storage  reorganization  is  triggered  only 
periodically.  Files  have  fields  corresponding  to  attribute  names 
in  the  conceptual  schema.  Fields  will  be  denoted  by  the 
corresponding  (or  compatible)  attribute  names  with  the  prefix  F. 

Indices  are  needed  both  for  fast  access  and  the  verification 
of  intentions.  Both  composite  (multi-attribute  searching  key) 
and  multiple  entry  (pointing  to  many  files)  indices  are  allowed. 
Composite  indices  are  needed  mainly  for  key  intentions.  Multiple 
entry  indices  are  needed  for  link  implementation. 
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A  graphic  presentation  of  the  internal  schema  is  used.  We 
indicate  separately  the  search  portion  of  the  indices.  We  also 
show  the  pointer  portion  of  the  index  as  a  group  of  pointers 
which  point  to  fields  of  different  files.  An  integer  on  the 
pointer  portion  will  demonstrate  an  upper  bound  on  number  of 
pointers  for  each  group  for  intention  purposes. 

We  give  in  Figure  V  the  internal  schema  corresponding  to  the 
conceptual  schema  as  presented  in  Figure  I.  Note  that  some 
indices  are  there  as  secondary  indices  for  fast  access,  e.g.,  12, 
Also  note  that  multiple  entry  indices  can  implement  more  than  one 
link,  e.g.,  11  implements  PRETOS,  PREREQS  and  OFFER  links. 

If  a  link  is  functional  it  implies  that  the  linking 
attribute  (s)  is  a  key  for  the  record  type,  e.g,,  FC#  in 
functional  PRETOS  implies  that  FC#  is  a  key  in  COORSE.  That  in 
turn  may  imply  that  another  link  is  functional,  e.g.,  OFFER,  All 
these  observations  are  consistent  with  the  meaning  of  link  and 
consistent  with  the  implementation,  e.g,,  11  implies  by  the 
presence  of  integer  (1)  that  FC#  is  key  in  FI  (COURSE),  and  that 
PRETOS,  PREREQS,  OFFER  links  are  functional. 

In  our  example  there  is  a  duplication  of  attributes  in 
different  files,  e.g.,  FC#,  in  Fl,  F2,  F3,  F4,  F6  and  II,  13. 
This  situation  may  seem  wasteful  and  redundant.  However,  if  we 
use  direct  pointers  between  files  to  eliminate  the  redundancy  the 
semantics  change,  especially  with  respect  to  insertion  and 
deletion. 

To  illustrate  data  manipulation  at  the  internal  level,  the 
network  query  is  further  translated  to  internal  form  in  figure  V. 
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Pointer  arrays  are  used  to  implement  selection  variables  and 
virtual  records.  The  internal  DML  is  presented  in  informal 
English  in  the  example. 

^x.  Concluding  remarks 

We  have  outlined  an  example  of  an  ANSI/SPARC  architecture. 
We  should  emphasize  that  this  example  is  a  research  tool  of 
limited  scope.  It  deals  with  only  a  few  problems  associated  with 
the  ANSI/SPARC  framework.  Our  example  is  meant  to  point  out 
problems  just  as  it  shows  solutions. 

We  are  not  proposing  an  abstract  model.  We  have  tried  to 
give  a  realistic  outline  of  a  system  architecture.  For  this 
reason  some  of  the  generality  which  is  very  appropriate  for  a 
model  is  sacrificed.  We  are  following  this  architecture  in  a 
real  system  design  [5].  The  system  is  further  restricted  to 
those  features  which  are  reasonable  to  implement  in  our 
environment  and  within  our  resources.  We  hope  that  our  system 
will  be  able  to  support  different  DBMS  approaches.  It  will 
definetely  not  support,  however,  other  existing  facilities  or 
systems. 
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Conceptual  Schema  Figure  I 


Examples  o£  Link  definitions 

LINK  PRETOS  FROM  COURSE  TO  PREREQ  WHERE  COURSE . C#=PREREQ . PRE# 

LINK  PREREQS  FROM  PREREQ  TO  COURSE  WHERE  COURSE . C#=PREREQ . C# 
FUNCTIONAL  AND  TOTAL 


LINK  ENROL  FROM  OFFERING  TO  ENROLMENT  WHERE  OFFERING. C#= 
ENROLMENT. C#  AND  OFFERING . OFF#=ENROLMENT . OFF# 


LINK  MANAGER  FROM  EMPLOYEE  TO  EMPLOYEE  ALIAS  BOSS 

WHERE  BOSS. EMP#=EMPLOYEE. MGR#  FUNCTIONAL  AND  TOTAL 
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Relational  View  Figure  II 

a)  Schema:  COURSE  TITLE) 

PREREQ(C#,PRE#}  OFFERING (C# , OFF# , DATE , LOG) 

TEACHING (C# ,OFF# ,EMP#)  ENROLMENT (G# , OFF #, EMP# , GRADE) 
EMPLOYEE (EMP# , NAME , ADDR , MGR# ) 


b)  External  query: 

GET  'ENROLMENT  WHERE  (1) 

(OFFERING. LOC=STOCKHOLM)  AND 
(OFFERING . C#=ENROLMENT . C# )  AND 
(OFFERING. OFF#=ENROLMENT. OFF#)  AND 
(ENROLMENT . GRADE=A) ' 

NUMS  ^  "READ  ' ENROLMENT . EMP# ' 

LI:  ->  0  IF  (p,NUMS)  =  0 

GET  'EMPLOYEE  WHERE  (EMPLOYEE . EMP#= ', If NUMS ,') '  (2) 

READ  'EMPLOYEE. NAME' 

NUMS  ^  If NUMS 
->  LI 


c)  Conceptual  translation: 

DEFINE  SELECTION  VARIABLE 
ENRLT  ON  ENROLMENT 
EMPL  ON  EMPLOYEE 

ENRLT  ^  SELECT  OFFERING  WHERE  LOG= ' STOCKHOLM'  (1) 

LINK  VIA  ENROL 

SELECT  ENROLMENT  WHERE  GRADE='A' 

OUTPUT  ENRLT 

EMPL  ^  SELECT  EMPLOYEE  WHERE  EMP#=106  (for  example)  (2) 
OUTPUT  EMPL 
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Hierarchical  View  Figure  III 


a)  Schema:  COURSE (C# , TITLE) 


PREREQ (PRE#, TITLE) 


OFFERING (OFF#, DATE, LOG) 


TEACHER (EMP# , NAME ) 


STUDENT (EMP# , NAME , GRADE) 


b)  External  query: 

GU  'OFFERING  WHERE  (LOC=STOCKHOLM) ' 

CONT 

LI:  GN  'OFFERING  WHERE  (LOC=STCCKHOLM) '  (1) 

CONT:  0  IF  STATUS^^O 

L2:  GNP  'STUDENT  WHERE  (GRADE=A) '  (2) 

->  LI  IF  STATUS^O 
READ  'STUDENT. NAME' 

^  L2 


c)  Conceptual  translation: 

DEFINE  SELECTION  VARIABLE 
OFF  ON  OFFERING 
STUD  ON  ENROLMENT 

DEFINE  VIRTUAL  RECORD  STUDENT 

SELECT  CURRENT  STUD  KEEP  GRADE 
LINK  VIA  EMPSTU  KEEP  EMP#, NAME 


On  first  loop  through  commands: 

FIND  FIRST  COURSE  (1) 

OFF  ^  SELECT  CURRENT  COURSE  LINK  VIA  OFFER 
FIND  FIRST  OFF  WHERE  LOC= ' STOCKHOLM ' 

OUTPUT  CURRENT  OFF (OFF# , DATE , LOC) 

PP  :=  'OFFERING';  PTP  :=  'OFFERING' 

STUD  ^  SELECT  CURRENT  OFF  LINK  VIA  ENROL  (2) 

FIND  FIRST  STUD  WHERE  GRADE='A' 

PP  :=  'STUDENT' 

OUTPUT  STUDENT 


54 


Network  View  Figure  IV 


a)  Schema 


PREREQS 


COURSE (C#, TITLE) 
OFFER 


PRETOS 


PREREQ(-) 


OFFERING (OFF# , DAT, LOG) 
TEACIi/^  'N^ROL 

ENROLMENT (GRADE) 


TEACHING (-) 

EMPTEACI^ 

EMPLOYEE (EMP#, NAME, ADDR, MGR#) 


^EMPSTU 


b)  External  query: 


GET  ’FIRST  OFFERING  RECORD  WHERE  (LOC=STOCKHOLM) '  (1) 

^  CONT 

LI:  GET  'NEXT  OFFERING  RECORD  WHERE  (LOC=STOCKHOLM) '  (2) 

CONT:  DONE  IF  STATUS;^ 0 

'ENROL'  CTC  'OFFERING'  (3) 

L2:  GET  'NEXT  ENROL  SET  WHERE  (GRADE=A) '  (4) 

^  LI  IF  STATUS^O 

'EMPSTU'  CTC  'ENROL'  (5) 

GET  'OWNER  EMPSTU  SET'  (6) 

READ  'EMPLOYEE. NAME' 

L2 


c)  Conceptual  translation: 


DEFINE  SELECTION  VARIABLE 
ENR0L_0  ON  OFFERING 
ENROL_M  ON  ENROLMENT 
EMPSTU_0  ON  ENROLMENT 
EMPSTU  M  ON  EMPLOYEE 


FIND  FIRST  OFFERING  WHERE  LOC= ' STOCKHOLM' 

OUTPUT  CURRENT  OFFERING (OFF# , DATE ,LOC) 

FIND  NEXT  OFFERING  WHERE  LOC= ' STOCKHOLM' 

OUTPUT  CURRENT  OFFERING (OFF# , DATE ,LOC) 

ENR0L_0  ^  SELECT  CURRENT  OFFERING 
enrol_set  :=  "new" 
if  enrol_set  =  "new" 

then  ENROL  M  ^  SELECT  ENR0L_0 

LINK  VIA  ENROL 
enrol  set  :=  not_new 
FIND  FIRST  ENROL_M  WHERE  GRADE='A' 
else  FIND  NEXT  ENROL_M  WHERE  GRADE='A'  £i 
OUTPUT  CURRENT  ENROL_M (GRADE) 

EMPSTU_0  ^  SELECT  CURRENT  ENROL_M  LINK  VIA  EMPSTU 
empstu_set  :=  "new" 

OUTPUT  EMPST  0 


(1.1) 

(1.2) 

(2.1) 

(2.2) 

(3.1) 

(3.2) 
(4.0) 
(4.1) 


(4.2) 

(4.3) 

(4.4) 

(5.1) 

(5.2) 
(6) 
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Internal  Schema  Figure  V 
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INTERNAL  translation:  Pointer  arrays  PA_OFF,  PA_E_0»  PA_E_M, 

. . .  must  be  declared. 

(1.1)  Enter  16  with  argument  'STOCKHOLM'  retrieving  the 
second  id  list.  Put  the  first  element  in  PA_OFF . 

(2.1)  Enter  16  with  argument  'STOCKHOLM'  retrieving  the 
second  id  list.  Find  the  first  id  in  the  list  greater 
than  the  contents  of  PA_OFF  and  put  it  in  PA_OFF. 

(2.2)  Output  the  last  3  fields  of  the  record  in  F2  with  id 
in  PA  OFF. 

(3.1)  Put  tKe  id  in  PA_OFF  in  PA_E_0. 

(4.1)  Get  the  FC#  and  FOFF#  values  of  the  record  in  F3  with 
id  in  PA_E_0.  Enter  13  with  this  pair  of  values  as 
argument  and  retrieve  the  thir^d  list  of  ids.  Put 
these  ids  in  PA  E_M. 

(4.2)  Starting  from  tlie  beginning  of  the  PA_E  M  list  use 
the  ids  to  get  records  from  F4.  Stop  wHen  a  record 
is  retrieved  with  FGRADE='A'.  Mark  this  id  as  the 
current  id  of  PA_E_M. 

(4.3)  Similar  to  4.2  but  start  with  the  next  id  after  the 
current  one. 

(4.4)  Like  2.2. 

'(5.1)  Like  4.1  but  using  FEMP#  and  1 4. 

(6)  Like  2.2. 
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The  Implementation  of  LSL 

by 

B.  Arlow,  J.  Klebanoff,  0,  Lapczak,  and  S.  Pozgaj 

Computer  Systems  Eesearch  Group 
University  of  Toronto 


Abstract 

LSL  is  a  data  base  language  designed  to  support  different 
data  models.  This  paper  describes  a  prototype  implementation  of 
LSL  on  a  PDP  11/45,  under  the  UNIX  operating  system.  The 
implementation  is  a  three  level  system  that  uses  simple  files  to 
stcre  record  types  and  E-trees  for  associative  access  structures. 
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1 .  Introduction 

LSL  (link  and  Selector  Language)  was  first  developed  by  D. 
Tsichritzis  in  1974  [10],  [11]«  It  was  initially  devised  as  an 
intermediate  language,  or  interface,  to  be  used  in  the 
implementation  of  a  relational  data  base  management  system. 
Since  then  LSL  has  evolved  both  in  form  and  motivation.  It  is 
now  conceived  of  as  a  self-sufficient,  network,  data  base 
language  that  can  support  several  different  data  models. 

Design  of  the  LSL  implementation  was  first  started  in  1975  by 
H.A.  Schmid  and  P.A.  Bernstein  [8],  [9].  Programming  of  the 
system  was  started  in  the  summer  of  1975  by  B.  Arlow,  R.  Baker, 
and  S.  Pozgaj.  The  implementation  underwent  an  evolution  that 
was  similar  to,  but  less  orderly  than,  that  of  LSL. 

This  paper  will  summarize  the  current  design  of  the  LSL 
implementation.  However  it  will  be  a  summary  only.  Details  can 
be  found  in  [6],  [1]  and  [4]. 

2 .  Summary  of  LSL 

This  section  will  give  a  terse  and  incomplete  summary  of  LSL. 
For  a  complete  description  of  the  language  see  [5]. 

The  basic  structure  in  LSL  is  a  record  type.  A  record  type 
is  a  named  collection  of  homogeneous  records.  Associated  with 
each  record  type  is  a  set  of  named  attributes.  An  attribute  is  a 
partial  function  from  a  record  type  to  a  set  of  numeric  values  or 
to  a  set  of  character  string  values.  Each  record  can  therefore 
be  considered  as  an  n-tuple,  perhaps  with  some  null  elements  in 
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the  tuple.  One  or  several  sets  of  attributes  may  be  designated 
as  keys, 

A  number  of  structures  may  be  defined  on  record  types.  A 
selector  is  a  named  subset  of  a  record  type.  It  is  defined  by  a 
Boolean  combination  of  terms  of  the  form  (attribute  op  constant) 
or  (attribute  op  attribute),  where  op  is  one  of  <,  <=,  =,  >= ,  > 
or  A  link  is  a  named  binary  relationship  between  two  record 
types  or  between  a  record  type  and  itself.  It  is  defined  by  a 
rule  of  the  form: (record_type, attribute  op  record_type.attrib ute) 
or  (record_type. attribute  =  record__type.  attribute  AND 
record_type. attribute  =  record__type, attribute  AND...), 

A  relation  is  a  much  more  complicated  structure  defined  on 
one  or  more  record  types  or  defined  as  the  union,  intersection  or 
difference  of  two  compatible  relations.  A  relation  may  be 
defined  on  several  record  types  with  a  definition  of  the  form: 

DEFINE  RELATION  relation- name  FROM  record-name 
[selection-clause]  [keep-clause] 

LINK  WITH  link-name  TO  record-name 
[selection-clause]  [keep-clause] 

LINK  WITH  .  . 

Each  selection  clause  defines  a  selection  from  the  previously 
named  record  type.  It  has  the  same  syntax  as  in  the  selector 
definition.  Each  keep-clause  defines  a  set  of  attributes  from 
the  previously  named  record  type  to  be  kept  in  the  relation. 

The  semantics  of  this  definition  is  not  obvious;  semantically 
the  definition  is  non-symmetric.  The  definition  must  be 
explained  procedurally.  One  starts  by  taking  the  records  from 
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the  first  record  type  that  are  selected  by  the  first  selection 
clause.  This  produces  a  set  of  records  {r^,  r^,  Then  the 
first  link  is  followed  to  produce  a  set  of  record  pairs  {(r^, 
s^)r  s2),  For  each  record,  r,  that  is  not  linked  to 
any  record  in  the  second  record  type  the  pair  (r,  null)  is 
introduced.  Then  for  each  tuple,  (r,  s) ,  the  record  s  is  checked 
to  see  if  it  satisfies  the  second  selector.  If  it  does  satisfy 
the  selector  the  tuple  is  retained.  Otherwise  the  tuple  is 
removed  and  tuple  (r,  null)  is  introduced.  Then  we  follow  the 
second  link.  For  each  pair  (r,s) ,  if  s  is  linked  to  records  in 
the  third  record  type  triples  of  the  form  (r,s,t)  are  produced, 
otherwise  triple  (r,s,null)  is  produced.  For  each  pair  (r,null) , 
triple  (r, null, null)  is  produced.  Then  the  third  selection 
clause  is  checked,  changing  some  of  thwe  (r,s,t)  triples  to 
(r,s,null)  triples.  This  process  is  continued  until  we  come  to 
the  end  of  the  definition.  tfe  end  up  with  tuples  of  the  form 
(r,s,t,...)  or  (r,s,t,...,null,nu 11 ...).  Ne  extract  a ttri bute 
values  as  dictated  by  the  keep  clauses,  or  where  the  tuples  are 
marked  as  null  we  introduced  null  values.  A  created  relation 
looks  like  a  record  type. 

The  definition  of  a  selector,  link,  or  relation  only  causes 
entries  to  be  made  in  the  schema  tables.  They  are  created  as  the 
result  of  a  create  command  or  when  they  are  refered  to  in  some 


other  command 
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3 .  System  Architecture 

The  LSL  system  proper  is  a  three  level  system  depicted  in 
figure  1,  The  system  consists  of  the  components  within  the 
dashed  rectangle  in  figure  1,  It  is  fired  up  as  a  separate 
process  under  UNIX  and  communicates  with  its  user  via  a  standard 
input  file  and  a  standard  output  file,  which  may  be  real  files  or 
pipes.  LSL  can  be  used  directly  by  a  user  at  a  terminal  or  it 
may  be  used  by  some  other  process  running  under  UNIX.  The  LSL 
processor  is  the  same  in  either  case. 

A  graphical  help  facility  for  browsing  through  a  data  base 
and  for  constructing  some  LSL  statements  has  been  developed  in 
conjunction  with  the  LSL  system.  This  facility  is  not  part  of 
the  LSL  system  proper.  It,  in  fact,  is  an  example  of  a  separate 
process  that  communicates  with  the  LSL  system  by  passing  LSL 
statements  through  a  pipe. 

The  upper  level  of  the  LSL  system  consists  of  two  modules: 
the  parser  and  the  interpreter.  The  parser  parses  incoming  LSL 
statements  to  see  that  they  are  syntactically  correct  and  checks 
all  names  (record  names,  attribute  names,  etc.)  to  see  that  they 
are  valid.  The  parser  translates  correct  LSL  statements  into  an 
internal  form  that  is  passed  to  the  interpreter.  The  parser 
accesses  the  schema  tables  to  test  the  validity  of  names,  to 
translate  previously  defined  names  into  internal  identification 
numbers  and  to  answer  schema  queries  presented  to  it  as  LSL  LIST 
statements.  However,  the  parser  does  not  modify  the  data  base, 
nor  does  it  access  any  of  the  actual  data. 
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figure  1 

The  interpreter  is  the  heart  of  the  system.  It  calls  base 
level  procedures  to  perform  the  data  retrieval,  data  modification 
or  schema  modification  specified  by  the  statements  sent  to  it  by 
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the  parser.  The  interpreter  cannot  be  accessed  directly  by  a 
user.  It  accepts  commands  only  from  the  parser  and  assumes  that 
the  commands  are  correct. 

The  base  level  is  a  heterogeneous  collection  of  more 
primitive  procedures.  Its  primary  functions  are  to  store  the 
actual  data,  to  store  access  paths  and  to  store  schema  tables. 
It  consists  of  three  main  modules:  the  file  structures  module 
which  implements  record  file  manipulation,  the  access  paths 
module  which  implements  B-trees  ' and  indexes,  and  the  system 
initialization  module.  The  system  initialization  module  is  used 
to  initialize  new  data  bases,  start  up  a  new  session  on  an 
initialized  data  base  and  to  end  a  session.  Like  most  such 
initialization  procedures  it  is  architecturally  ugly  but, 
fortunately,  it  is  fairly  small  in  our  case. 

Because  the  LSL  system  is  fairly  large  and  the  PDP-11  virtual 
address  space  is  not,  the  LSL  system  is  run  as  two  processes  with 
separate  address  spaces.  The  interpreter  and  its  attendant  base 
level  procedures  are  run  as  a  child  process  of  the  parser 
process. 

This  splitting  of  the  LSI  system  into  two  processes  was  done 
solely  to  accommodate  the  system  to  a  small  virtual  address 
space.  It  is,  otherwise,  not  a  significant  architectural  feature 
of  the  system.  The  two  processes  are  synchronized  so  that,  once 
certain  initializations  have  been  performed,  only  one  of  the  two 
is  running  at  a  time.  The  parser  parses  one  LSL  statement  at  a 
time  and  waits  for  the  interpreter  to  finish  with  the  statement 
before  parsing  the  next  statement.  Consequently  the  interpreter 
must  wait  for  the  parser  before  it  can  get  the  internal  code  for 
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a  statement.  The  interpreter  is  essentially  called  by  the  parser 
like  a  procedure. 

^ •  The  Parser  and  Interpreter 

The  parser  is  a  top-down  parser  that  uses  the  recursive 
descent  method.  Its  structure  is  reasonably  close  to  the  BNF 
grammar  of  LSI  given  in  the  user's  manual. 

The  code  produced  by  the  parser  is  a  concatenation  of 
integers  and  even  length  byte  strings.  The  first  word,  the 
command  type  word,  indicates  which  command  is  being  represented, 
and  what  type  of  object  is  to  be  operated  upon.  The  structure  of 
the  rest  of  the  code  depends  on  the  type  of  the  command.  In 
general,  previously  defined  entity  names  (record  names,  link 
names  etc.)  are  translated  into  integers  used  to  index  the 
relevant  schema  tables.  Boolean  expressions  used  in  selection 
clauses  are  represented  as  trees. 

As  was  the  case  with  the  parser,  there  are  few  general 
remarks  that  can  be  made  about  the  interpreter.  It  reads  the 
command  code.  Then,  based  on  the  command  type  word  it  selects  a 
procedure  that  interprets  that  type  of  command  code.  The  same 
procedure  is  used  for  both  the  LOAD  and  CLEAR  AND  LOAD  command 
types.  Otherwise  there  is  one  such  command  procedure  for  each 
command  type. 
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5 .  Schema  Tables 

There  are  five  different  structures  in  LSL:  record  types, 
attributes,  selectors,  links  and  relations.  Each  LSL  data  base 
has  five  corresponding  schema  tables  to  describe  the  instances  of 
each  of  these  types  of  character.  Thus  each  data  base  has  a 
record  type  table  (ET  table),  an  attribute  table  (sometimes 
referred  to  as  the  domain  table  in  previous  LSL  documentation) ,  a 
selector  table^  a  link  table,  and  a  relation  table. 

Each  of  the  tables  is  stored  as  an  array  on  a  file. 
Internally,  each  record  type,  link,  selector  and  relation  is 
identified  by  its  index  in  its  table.  Attributes  are  treated 
differently.  The  attribute  table  is  indexed  by  a  record  type 
number  and  an  attribute  number  that  is  unique  only  within  the 
record  type.  The  attribute  table  entry  for  the  i*th  attribute  of 
the  j*th  record  type  is  found  in  slot  20j  +  i  in  the  attribute 
table.  (Each  record  type  can  have  a  maximum  of  20  attributes.) 
The  record  type  link,  selector  and  relation  table  entries  all 
have  variable  length  portions.  These  variable  length  portions 
are  stored  separately,  either  as  a  number  of  entries  on  a  B-tree, 
or  on  a  file  that  has  been  set  up  for  variable  length  allocation. 

The  record  type  table  and  the  attribute  table  are  handled 
entirely  by  the  file  structures  module  of  the  base  level.  They 
are  stored,  together  with  the  B-tree  headers,  on  a  file  called 
the  “sysinfo"  file.  The  other  tables  are  handled  more  directly 
by  the  interpreter  and  are  stored  on  separate  files. 

None  of  the  schema  tables  contain  the  user  defined  entity 
names.  Instead  these  names  are  stored  in  B-trees;  there  is  one 
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such  B-tree  for  each  schema  table.  In  the  case  of  the  record 
type,  link,  selector  and  relation  table  B-tree  the  key  of  each 
entry  is  a  user-defined  name.  The  information  field  is  the 
schema  table  entry  index.  In  the  case  of  the  attribute  table  B- 
tree  the  key  consists  of  the  record  type  number  followed  by  the 
attribute  name;  the  information  field  contains  the  attribute 
number.  The  B-trees  allow  fast  translation  from  the  user-defined 
names  to  internal  identification  numbers.  They  also  allow 
aliases  to  be  treated  exactly  the  same  as  primary  names. 

6 .  Record  Types 

Record  types  are  controlled  entirely  by  the  base  module. 
Each  record  type  is  stored  as  an  array  of  fixed  length  records  on 
its  own  file.  Each  record  has  one  field  and  one  null-flag  bit 
for  each  attribute  of  the  record  type.  The  null-flags  are  used 
to  indicate  whether  the  corresponding  attribute  is  null  or  not. 
These  flags  are  collected  together  at  the  front  of  each  record. 
Deleted  records  have  all  their  null  flags  set  on  and  are  chained 
together. 

A  record  type  is  described  by  entries  in  the  RT  table,  the 
attribute  table  (sometimes  referred  to  as  the  domain  table)  and 
by  the  keylog  table.  Each  RT  table  entry  contains  the  length  of 
the  records,  the  number  of  records,  the  name  of  the  file,  the 
number  of  attributes,  a  pointer  to  a  keylog  table  entry,  and  some 
other  information.  Each  attribute  table  entry  contains  the 
length  of  the  attribute  values,  their  offset  in  the  records, 
whether  the  attribute  is  indexed  and  other  information.  Each 
keylog  table  entry  is  a  variable  length  record  describing  all  the 
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keys  of  the  record  type.  Only  the  attribute  table  is  visible 
above  the  base  level  modules.  The  RT  table  and  keylog  table  are 
used  solely  by  the  base  level. 

7 .  B- tree s 

A  B-tree  [2],  [3]  is  a  data  structure  used  for  storing  data 
of  the  form  (key,  information),  sorted  on  the  key  values.  The 
data  structure  allows  fast  searches,  insertions,  and  deletions. 
It  also  allows  fast  sequential  access  to  the  data.  A  B-tree  is  a 
multi-way  tree  with  the  restriction  that  every  node  other  than 
the  root  must  be  at  least  half  full  and  the  tree  is  height- 
balanced,  The  maximum  size  of  a  node  is  the  page  size  of  the 
file  system  (512  bytes  in  UNIX) . 

There  are  a  number  of  variations  on  3-trees.  The  type  we  use 
requires  that  all  key  fields  in  the  same  B-tree  be  of  the  same 
size  and  that  all  information  fields  in  the  same  B-tree  be  of  the 
same  size.  (Different  B-trees  may  have  different  key  and 
information  field  sizes.)  All  information  is  stored  on  the  leaf 
nodes  of  the  tree,  non-leaf  nodes  contain  key  values  that 
duplicate  key  values  stored  on  the  leaves.  All  nodes  on  the  same 
level  are  doubly  linked  together  in  order  by  key  values.  Thus  a 
B-tree  in  our  system  can  be  thought  of  as  a  chain  of  nodes 
containing  the  sorted  data  with  a  directory  on  top  of  the  chain. 

To  simplify  the  use  of  B-trees  each  B-tree  has  a  header  that 
describes  the  tree  and  points  to  the  root  of  the  tree.  These  B- 
tree  headers  are  stored  and  manipulated  completely  under  the 
control  of  the  B-tree  module.  Furthermore,  all  B-trees  are 
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stored  on  the  same  file.  Therefore,  after  a  B-tree  has  been 
created  it  is  identified  and  described  solely  by  an 
identification  number  that  points  to  the  B-tree  header. 

8 .  Indexes 

An  index  is  a  data  structure  used  to  speed  up  searches  on 
particular  attributes.  The  same  data  structure  is  used  to  store 
created  links.  We  call  the  type  of  index  used  in  our 
implementation  "multi-entry"  indexes.  One  index  structure  can  be 
used  to  index  several  different  but  compatible  attributes. 

Conceptually  an  index  stores  triples  of  the  form;  (v,g,r). 
Here,  v  is  an  attribute  value  or  a  concatenation  of  attribute 
values,  A  concatenation  of  attribute  values  is  used  to  represent 
a  link  with  a  definition  of  the  form  LINK  1  BETWEEN  r  AND  s  WHERE 
r.ai=s.bi  AND  r.a2=s.a2...  ,  in  this  case  each  v  is  a 
concatenation  viv2...  ,  When  a  concatenation  of  attributes  is 
indexed  like  this  the  index  can  only  be  used  for  the  one  link. 
If  only  simple  values  are  indexed  the  index  can  be  used  for  any 
number  of  compatible  links  and  simple  indexes.  The  r  value  in 
the  triple  is  a  record  number,  a  pointer  to  a  record  in  a  record 
file.  The  g  value,  is  called  the  group  number.  For  indexes  on 
simple  values  it  indicates  the  record  type  and  attribute  that  the 
triple  pertains  to.  For  indexes  on  composite  attributes  the 
group  number  indicates  which  side  of  the  link  the  triple  pertains 
to. 


LSL  multiple  entry  indexes  are,  more  or  less,  built  out  of  B 
trees.  Each  entry  in  the  B-tree 


has 


the 


f  orm ; 


68 


(v,gOrrO,g*,rirg^rr2) ,  v  is  an  attribute  value  and  is  the  key 
part  of  the  entry.  The  g  and  r  fields  are  group  numbers  and 
record  numbers  respectively.  Obviously  a  given  attribute  value 
may  be  associated  with  more  or  less  than  three  records.  If  a 
value  is  associated  with  only  one  or  two  records  then  g^  or  both 
g*  and  g2  will  have  a  null  value  (-1).  If  a  value  is  associated 
with  more  than  three  records  then  gO  will  have  a  null  value  and 
ro  will  point  to  a  B-tree  that  holds  all  the  (grT)  pairs 
associated  with  the  attribute  value.  Thus  one  multiple-entry 
index  may  be  composed  of  a  number  of  B-trees. 

While  multiple-entry  indexes  can  be  conceived  of  as  being 
built  on  top  of  B-trees,  in  fact  the  implementations  of  B-trees 
and  multiple-entry  indexes  are  somewhat  tangled.  (This  was  not 
one  of  oiir  better  ideas.)  Multiple-entry  indexes  are  considered 
to  be  a  special  kind  of  B-tree.  When  a  B-tree  is  created  it  can 
be  designated  to  be  a  multiple-entry  index.  A  field  in  the  B- 
tree  header  indicates  what  type  of  B-tree  it  is.  The  same 
procedure  is  used  for  insertions  into  both  kinds  of  B-tree. 

9 •  The  Graphical  Facility 

The  graphical  facility  was  designed  to  help  users  browse 
through  record  type,  link,  selector  and  relation  definitions  and 
to  help  them  define,  create,  output  ^and  brouse  through  relations. 
Its  most  significant  feature  is  the  pictorial  representation  of 
record  types,  links,  selectors  and  relations  on  a  line  drawing 
CRT  display  terminal.  The  interface  with  the  graphics  devices  is 
handled  by  GPAC  [7],  a  graphical  input  and  output  package 
developed  at  the  University  of  Toronto. 
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When  the  graphical  facility  starts  up  it  sets  up 
communication  pipes  and  fires  up  the  LSL  processor.  It  then 
sends  an  LSL  request  for  the  names  of  all  the  record  types  in  the 
data  base.  Further  schema  queries  are  made  when  and  as  needed. 
Menu  0  is  then  posted  on  the  screen  and  the  program  waits  for  the 
user  to  specify  what  action  he  wants  to  take. 

There  is  little  more  of  a  general  nature  that  can  be  said 
about  the  graphical  facility.  For  details  about  the 
implementation  see  [4].  A  user's  manual  for  the  graphical 
facility  can  be  found  in  [4]  and  is  reproduced  in  [5]. 


1 0 .  Conclusion 

At  the  time  of  this  writing  (Feb.  1977)  a  first 
implementation  of  LSL  is  almost  complete.  This  first 
implementation  will  lack  some  of  the  features  of  LSL.  In  the 
first  version  only  one  user  may  use  a  data  base  at  a  time  and 
only  equality  links  are  allowed. 

The  current  implementation  of  LSL  leaves  many  things  to  be 
desired.  We  are  aware  of  many  design  flaws  and  some  poor 
programming.  However,  it  should  be  kept  in  mind  that  this  is  a 
prototype  system.  It  was  built  as  a  feasibility  study  of  a 
multi-model  architecture.  It  will  take  a  great  effort  to  turn  it 
into  a  production  system.  In  a  university  we  build  prototypes 
mainly  for  research  purposes.  Other  people  can  use  the  ideas  in 
commercially  oriented  systems. 
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Abstract 

There  is  much  discussion  about  back  end  data  base 
systems.  In  this  paper  we  describe  MINIREL,  a  front  end 
data  base  management  system.  MINIREL  is  designed  and 
implemented  on  a  desk-top  computer,  the  IBM  5100.  As  a 
stand-alone  DBMS,  MINIEEL  can  be  used  for  small 
applications.  For  larger  applications,  it  can  be  used  as  a 
front  end  to  access  the  data  base.  The  user  obtains  a 
portion  of  the  data  base  from  some  node  in  a  network.  He 
then  proceeds  manipulating  the  data  locally. 
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^ •  Introduction 

There  is  much  discussion  in  the  literature  about  back 
end  data  base  computers.  In  this  paper  we  look  at  exactly 
the  other  end  of  the  information  system,  namely  front  end 
data  base  systems.  Let  us  assume  that  there  will  be  a  great 
demand  for  casual  user  interfaces  to  data  base  management 
systems  (DBMS)  [3].  It  would  be  very  hard  to  accomodate 
this  demand  by  terminals  connected  to  centralized  systems. 
We  need  to  factor  out  some  of  the  data  base  activity  right 
on  the  terminal.  Terminals  are  becoming  increasingly 
sophisticated.  They  are  handling  graphics,  text  editing, 
etc.  They  should  be  able  to  take  some  load  of  the  data 
access  activity.  In  this  paper  we  present  a  system  which 
serves  as  a  positive  feasibility  study  of  this  approach. 

The  IBM  5100  is  a  desk-top  computer  which  can  be  thought 
of  as  an  intelligent  terminal  (there  may  be  some  doubts  on 
how  intelligent) .  It  can  access  another  system  as  a 
terminal  and  it  can  be  programmed  to  work  on  its  own.  It 
has  a  limited  number  of  peripherals  for  I/O  and  secondary 
storage.  It  has  nothing  extraordinary,  except  perhaps  its 
compactness.  As  a  matter  of  fact,  we  expect  many  more 
machines  of  this  variety  which  will  be  faster,  cheaper  and 
better. 

We  designed  and  implemented  a  small  relational  data  base 
system,  MINIREL,  on  the  IBM  5100  [7].  The  main  reason  for 
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selecting  the  relational  approach  was  its  simplicity  for  the 
end  user* 

The  WINIEEL  system,  as  a  stand-alone  DBMS  on  the  5100, 
is  limited  to  very  small  applications;  the  main  limiting 
factor  is  the  hardware.  However,  it  can  be  used  for  larger 
applications  in  a  distributed  function  with  other  5100s  and 
larger  systems.  In  our  particular  environment  we  have  a 
homogeneous  distributed  system  [4], 

MINIEEL  is  compatible  with  the  relational  part  of  EDBS 
[5],  The  two  systems  (MINIEEL  and  EDBS)  can  talk  to  each 
other,  with  the  5100  operating  as  a  terminal  of  the  remote 
system.  MINIREL  and  EDBS  support  the  same  data  types  and 
formats,  and  the  main  data  manipulation  and  data  definition 
commands  have  an  identical  syntax.  The  5100s  and  the  IBM 
mainframes  (360/370  series) ,  on  which  EDBS  is  running,  are 
considered  as  nodes  in  a  homogeneous  distributed  system. 

To  clarify  this  point,  we  will  present  some  example 
system  configurations  that  have  been  tested  in  the 
University  of  Toronto, 

Consider  a  typical  MINIREL  user.  He  uses  relational 
EDBS  data  bases  on  a  central  system  and  has  the  5100 
(supporting  MINIREL)  on  his  desk.  The  user  can  effectively 
utilize  his  5100  by: 

a)  Sending  the  EDBS  data  base  tables  and  data  to  the  5100 

and  creating  the  corresponding  MINIREL  data  base.  The 
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MINIREL  data  base  will  have  the  same  schema  and  the  same 
data  as  the  EDBS  data  base, 

b)  The  EDBS  data  base  may  be  very  large  and/or  some  of  the 
relations  may  not  be  of  any  interest  to  the  user.  He 
may  create  a  MINIEEL  data  base  based  on  a  subschema  of 
the  original  EDBS  data  base.  Then,  he  may  transfer  the 
data  for  the  MINIEEL  relations  from  the  EDBS  data  base. 

c)  An  extension  of  the  previous  scenario  can  be:  The  user 
may  be  interested  not  only  in  some  of  the  EDBS 
relations,  but  also  in  some  joins  or  projections  of  the 
other  data  base  relations  (which  are  themselves 
relations) ,  Creating  the  "snapshots"  of  these 
combinations  (EDBS  retrievals)  he  may  transfer  the  data 
to  the  5100.  The  MINIREL  system  will  consider  these 
snapshots  as  stored  data  base  relations,  described  in 
the  DDL  schema.  The  example  in  (b)  can  be  extended  with 
the  additional  assumption  that  the  user  is  interested  in 
a  different  organization  of  the  information, 

d)  He  may  avoid  connect  time  and  network  manipulation  by 
having  the  same  data  base  in  both  systems.  Information 
is  processed  by  the  5100,  changes  of  the  data  base  are 
stored  separately  on  tape,  and  later  transmitted  to 
another  system. 

Ideally,  in  a  distributed  system,  the  user  should  not  be 

aware  of  the  physical  distribution  of  the  data.  In  the 
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actual  implementation,  though,  of  the  above  scenarios,  we 
imply  complete  understanding  of  the  environment  by  the  user. 
We  think  this  is  a  first  step  towards  a  realistic 
implementation  of  distributed  systems.  Use  of  MINIREL  in  a 
distributed  fashion  requires  two  modes  of  operation.  The 
user  first  works  with  the  MINIREL  system  on  the  5100  and 
then  enters  the  communications  mode  to  transmit  his  results 
to  the  remote  system.  Conversely,  the  user  first  works  with 
the  EDBS  on  another  system  while  in  communications  mode, 
stores  his  results  on  tape,  and  then  returns  to  local  5100 
mode  to  receive  the  results. 

The  remainder  of  the  paper  describes  using  examples 
(Sequel-like  presentation,  [2])  the  MINIREL  system,  gives  an 
implementation  outline,  and  concludes  with  the  current 
status  of  MINIEEL  and  its  applications, 

2 •  Data  Definition 

We  describe  the  MINIREL  language  by  a  series  of  examples 
based  on  the  data  base  of  Fig.l,  We  chose  this  data  base 
because  it  actually  exists  as  a  "real"  application  of  the 
MINIREL  system.  For  simplicity  we  omit  other  relations 
which  exist  in  the  application  and  deal  with  the  students* 
supervisors,  current  research,  financial  support 
(scholarships,  awards)  etc. 
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STUDENT (name, student-no,  status-in-canada,  degree- 
program,  year- in- program,  field,  full-part¬ 
time) 

STUDENT-ADDRESS  (student-no,  mailing-address,  tel-rno, 

room-address,  room-tel-no) 

COURSES (course-code,  title,  year,  instructor,  no-of- 
students) 

COURSES-TAKEN (student-no,  course,  year,  grade) 

Fig.  1. 

MINIREL  data  definition  facilities  enable  the  user  to 
create  and  destroy  data  bases  or  to  insert  and  drop 
relations  in  an  existing  data  base.  A  data  base  creation  is 
based  on  its  description.  The  data  base  description  is 
given  in  the  schema.  The  schema  describes  all  units  of 
logical  data  and  the  relationships  that  exist  among  them. 
All  logical  units  of  data  are  also  named  and  where 
appropriate,  the  type,  size  etc.  of  the  units  is  also  given. 

MINIREL  permits  relations  to  be  inserted  and  dropped 
dynamically.  The  user  specifies  the  name  of  the  relation 
and  the  names  and  data  types  of  its  domains. 

3 .  Data  Manipulation 

Relations  (tables,  matrices)  are  manipulated  and  related 
by  means  of  relational  operators.  These  operators  may  be 
based  on  the  relational  algebra,  the  relational  calculus  or 
equivalent  operations,  e. g, ,  mapping-oriented  or  graphics- 
oriented  ([1],  [6]).  MINIREL  is  calculus-oriented. 
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A  typical  query  (retrieval  of  information  from  the  data 
base)  has  two  parts:  a  target-list,  which  specifies  the 
particular  domains  in  the  particular  relation (s)  which  are 
to  be  returned,  and  a  where-clause,  which  selects  particular 
tuples  from  the  target  relation (s)  by  giving  a  condition 
which  they  must  satisfy. 

Our  first  example  query  consists  only  of  a  target  list, 
corresponding  to  a  projection.  In  MINIEEL  the  duplicates 
are  not  removed.  We  have  this  restriction  because 
elimination  of  duplicate  values  is  an  expensive  operation. 
In  addition,  semantically,  the  elimination  may  sometimes  not 
be  desired, 

Exi,  Find  the  names  of  all  graduate  students, 

GET  ' STUDENT. NAMP* 

A  where- clause  may  specify  a  restriction.  The 
restriction  operation  selects  only  those  tuples  of  a 
relation  which  satisfy  a  given  condition,  A  condition 
allows  comparison  of  a  tuple  component  with  a  user-supplied 
constant  value.  Comparisons  can  be;  <,  <,  >,  >,  and  =. 
Ex2,  is  a  combination  of  projections  and  restrictions, 

Ex2,  Find  the  names  and  full/part  time  status  for  all 

students,  who  are  more  than  three  years  into  their 
Ph.D,  program, 

GET  'STUDENT, NAME,  STUDENT. FULL_PART_TIME 
WHERE 

(STUDENT. DEGEEE_PROGRAM  =  PHD)  AND 
(STUDENT. YEAR_IN_PROGRAM  >  4)* 
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In  a  join  operation,  two  relations  are  selected  and  a 
new  relation  is  formed  by  concatenating  a  tuple  from  the 
first  with  a  tuple  of  the  second  relation  wherever  a 
condition  holds  between  them.  All  joins  in  MINIREL  are 
natural  joins.  That  is,  data  is  selected  from  two  relations 
based  on  the  equality  of  the  components  in  two  domains,  one 
from  each  relation.  The  join  is  implicit  in  MINIREL  and  is 
triggered  by  the  appearance  of  a  join  condition  in  the 
where-clause,  as  Ex3.  shows. 

Ex3.  Find  the  courses  in  which  student  John  Smith 
enrolled  and  the  grades  he  received. 

GET  *COURSES_TAKEN. COURSE,  COURSES_TAKEN. GRADE 
WHERE 

(STUDENT. NAME  =  SMITH  JOHN)  AND 
(COURSES^TAKEN. STUDENT_NO=STDDENT. STUDENT^NO) » 

Alternative  "views"  which  are  derived  from  the  stored 
data  is  a  very  important  aspect  in  relational  systems.  A 
"view"  can  be  defined  as  a  dynamic  window  of  a  data  base. 
MINIREL  offers  the  facility  to  define  "limited  views"  with 
pre-canned  commands.  These  views  can  be  thought  of  as 
derived  relations,  which  cannot  be  operated  on,  as  can 
stored  relations  in  the  data  base.  They  can  be  retrieved 
and  partially  projected,  but  they  cannot  be  restricted  or 
joined  with  other  stored  relations  or  views.  Any  change  of 
the  underlying  relation (s)  is  reflected  in  these  limited 
views  but  the  views  cannot  be  modified  directly. 
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Ex4,  Define  a  view  containing  the  student  number  and 

the  course's  description,  for  all  courses  and  all 
students  that  attended  the  courses  in  a  certain 
year* 

DEFINE  'COOESES,  CODESES^TAKEN. STUDENT_NO 
WHEEE 

(CODESES.COUESE_CODE=COUBSES  TAKEN. COUESE) 
AND  (COURSES. YEAE  =  )' 


A  number  is  assigned  (chronologically)  to  each  defined 
view  by  the  system.  At  definition  time,  the  user  does  not 
specify  the  parameter  constant  value  (the  year  for  example). 
The  parameter  (s)  are  supplied  by  the  user  interactively  with 
the  GET  SELECT  command. 


Ex5.  Eetrieve  the  view  defined  before,  for  year  1976. 
GET  'SELECT  QUEEY  n' 

ENTER  THE  VALUE  OF  YEAE:  (system's  response) 

->  76  (user  supplied  data) 


A  user  does  not  manipulate  data  directly  in  MINIEEL.  A 
buffer  is  provided  for  him,  where  retrieved  data  or  new  data 
for  the  data  base  is  placed.  This  buffer  acts  as  the 
interface  between  MINIEEL  and  APL  for  the  transfer  of  data. 
The  buffer  can  be  accessed  with  the  READ,  WRITE,  and  REWRITE 
buffer  commands.  The  READ  command  has  formats  that  allow 
further  restriction  and/or  projection  of  the  retrieved 
tuples. 

The  MINIREL  modification  commands  are  PUT  (to  insert  new 
tuples  in  a  relation)  ,  DELETE  (to  remove  tuples  from  a 
relation) ,  and  UPDATE  (to  alter  tuples) . 
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Insertion  of  a  single  tuple  is  illustrated  by  Ex6.  The 
WRITE  command  places  the  tuple  in  the  buffer.  The  PUT 
command  takes  the  tuple  from  the  buffer  and  places  it  into 
the  data  base.  Attributes  are  separated  by  commas.  Notice 
that  the  FIELD  value  is  not  specified  by  the  insertion 
statement;  it  is  given  a  null  value. 


Ex6.  Insert  a  new  full-time  student  named  *  SMITH*  with 

student  number  30000.  The  new  student  is  a  Canadian 
citizen,  in  the  first  year  of  his  Msc  program. 

•SMITH,  30000,  CITIZEN,  MSC,  1,  ,F' 

WRITE  'STUDENT* 

POT  'STUDENT* 


Another  way  of  inserting  tuples  is  illustrated  by  the 
next  example.  A  previously  dynamically  inserted  relation, 
MSC_OLDTIMERS,  with  domains:  NAME,  TEL_NO  and  FIELD  is 
assigned  data.  A  query  is  first  issued  and  the  retrieved 
data  in  the  buffer  is  transferred  to  the  specified  relation. 


Ex7.  Find  the  names,  telephone  numbers  and  fields  of 
interest  of  all  Msc  students  that  have  more  than  2 
years  in  their  program.  Enter  the  retrieved  tuples 
in  the  relation  MSC  OLDTIMERS. 

GET  'STUDENT. NAME,  STUDENT_ADDEESS . TEL_N0, 

STUDENT. FIELD 
WHERE 

(STUDENT. DEGREE_PEOGRAM  =  MSC)  AND 
(STUDENT. YEAR_IN_PEOGRAM  >  2)  AND 
(STUDENT. STUDENT.NO  = 

student_address7stddent_no) * 

ASSIGN  'MSC  OLDTIMERS* 


In  a  deletion,  tuples  to  be  removed  from  the  data  base 
are  specified.  Syntactically,  the  DELETE  is  very  similar  to 
the  GET  command  (projection  is  not  allowed) . 
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Ex8.  Delete  from  CODE SES_TAKEN  all  the  courses  that 
student  with  student  number  50001  has  taken. 

DELETE  'COURSES  TAKEN 
WHERE 

(COUESES^TAKEN. STODENT_NO  =  50001)* 


In  an  update,  the  tuples  to  be  altered  must  first  be 
retrieved  and  placed  in  the  buffer.  The  REWRITE  command 
alters  the  tuples  and  finally,  the  UPDATE  command  takes  the 
altered  tuples  from  the  buffer  and  replaces  them  in  the  data 
base. 


Ex9.  Update  the  COURSES^! AKEN  relation  by  granting 
a  B  to  all  students  who  had  a  B-minus  before. 

GET  'COURSES_TAKEN 
WHERE 

(COURSES^TAKEN. GRADE  =  B-)  • 

'B'  REWRITE  '*^CO UR SES^TAKEN.  GRADE* 

UPDATE 


In  MINIREL,  the  user  specifies  his  intention  to  begin 
accessing  a  data  base  by  an  OPEN  command.  In  response,  the 
system  opens  physical  files,  allocates  a  buffer,  system 
tables  etc.  A  CLOSE  command  signals  the  DBMS  to  clean-up 
processing.  Additional  utilities  are  provided  in  MINIREL: 


COMMANDS  - 

STRUCTURE  - 

SHOW 

TUPLES 

TUPLESDELETED 


gives  a  short  description  and  the  syntax 
for  every  MINIREL  command, 
produces  a  description  of  the  data  base, 
presents  the  pre-canned  queries, 
returns  the  number  of  tuples  in  the  buffer, 
gives  the  number  of  tuples  deleted 
in  the  last  DELETE  command. 
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There  is  a  system-defined  global  variable,  STATUS,  which 
is  set  after  every  MINIEEL  command,  indicating  whether  the 
command  succeeded  or  not.  Its  main  purpose  is  to  allow  the 
user  to  control  the  order  of  statements  executed  in  an  APL 
function.  The  use  of  commands  within  user-defined  APL 
functions  is  shown  in  ExIO. 


Ex10.  For  student  WHO,  find  the  field  of  interest  and 
list  all  courses  he  has  succesfully  completed. 

EEPOET  WHO 

[1]  GET  ’STUDENT  WHERE  (STUDENT. NAME  =*,WHO,*)* 

[  2]  ->END  IF  STATUS  0 

[3]  ’THE  STUDENT  NAMED  ’,WHO,’  IS  INTERESTED  IN:' 

[4]  ”  READ  ’STUDENT. FIELD’ 

[5]  NO  <-  ”  READ  ’ STUDENT. STUDENT^NO’ 

[6]  GET  ’COURSES. TITLE  WHERE  (COURSES  TAKEN. STUDENT_NO=NO) 

AND  (COURSES. COURS ENCODE  =  COURSES^TAKEN. COURSE  ) 
AND  (COURSES^TAKEN. GRADE  #  F) ’ 

[7]  ->END  IF  STATUS 

[8]  ->NONE  IF  TUPLES  =  0 

[9]  'HE  COMPLETED  SUCCESFULLY  THE  FOLLOWING  COURSES:’ 

[  10  ]  ”  READ  ’ALL’ 

[  11  ]  ->END 

[12]  NONE:  ’HE  DID  NOT  COMPLETE  ANY  COURSE  SUCCESFULLY’ 

[13]  END:  ’END  OF  REPORT’ 


^ •  Implementation 

Before  we  discuss  the  system’s  implementation,  it  is 
useful  to  provide  a  short  description  of  the  machine,  so 
that  the  reader  will  be  familiar  with  the  environment.  The 
IBM  5100  is  a  desk-top,  compact,  computer.  It  is 
micro programmable  by  IBM  but  not  by  the  user.  Main  memory 
for  the  unit  includes  up  to  200  k-bytes  of  Read  Only  Storage 
(ROS) .  Data  memory  (Read/Write)  ranges  from  16  to  64  k- 
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bytes.  The  unit  includes  a  typewriter-like  keybord,  a  small 
diagonal  CRT,  and  a  tape  drive  for  a  200  k-byte  cartridge. 
There  may  be  at  most  two  peripherals  attached  to  the 
machine:  a  printer  and  an  auxilliary  tape-drive  unit.  The 
sequential  nature  of  the  secondary  storage  and  the 
limitation  on  the  number  of  peripherals  are  certainly 
disadvantages  for  the  system.  Two  interactive  languages, 
APL  SV.6  and  BASIC,  are  offered.  However,  the  language 
interpreters  are  very  slow,  with  a  considerable  amount  of 
overhead  between  function  calls.  There  exists  a 
Communications  Adapter  feature  that  enables  the  5100  to 
transmit  data  to  and  receive  data  from  a  remote  system.  The 
5100  appears  the  same  as  an  IBM  2741  Communications  Terminal 
to  the  mainframe.  Data  can  be  entered  from  the  5100  keybord 
or  tape  unit,  and  limited  length  messages  can  be  printed 
and/or  written  on  a  tape  cartridge. 

The  MINIREL  system  is  small  and  simple.  No  great 
optimizing  strategies  were  employed  for  storage  allocation 
and  retrieval.  In  designing  a  DBMS  for  such  a  small 
computer  the  main  difficulties  are  presented  by  the  machine 
limitations. 

Each  MINIREL  command  is  implemented  as  an  APL  function. 
The  argument  is  a  character  string  which  is  interpreted. 
The  interpretation  of  the  commands  is  mainly  syntax 
oriented.  In  implementing  the  system  functions  we  tried  to 
take  full  advantage  of  APL*s  exceptionally  good  table 
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facilities.  For  example,  whenever  possible,  relational 
operations  are  performed  with  APL  inner-'-matrix  products. 
Since  controlled  repetition  (loops)  is  an  extremely  slow 
operation  on  the  5100,  we  avoided  loops  throughout  the 
implementation,  by  using  data  structures  and  APL  array 
operators. 

A  MINIREL  data  base  consists  of  a  set  of  files.  Each 
relation  is  implemented  as  a  separate  APL.SV  file  on  a  tape 
cartridge.  Relations  are  stored  as  character  string 
matrices  with  a  varying  number  of  rows  and  a  specified 
number  of  columns.  Each  row  of  the  matrix  is  a  relation 
tuple.  A  file  is  reserved  for  keeping  the  data  base  tables 
and  system  messages.  Another  special  file  is  needed  for 
saving  the  pre'-canned  queries.  There  may  be  more  than  one 
(small)  data  base  on  a  tape  cartridge.  On  the  other  hand,  a 
data  base  may  occupy  at  most  two  tape  cartridges 
(approximate!! y  400K  bytes). 

The  system  imposes  a  restriction  on  the  size  of  the 
relations  in  a  data  base.  The  user  should  keep  the  data 
base  relations  small  by  splitting,  for  example,  relations 
with  binary-value  domains.  The  number  of  relations  is  not  a 
severe  limiting  factor  for  the  system’s  performance. 
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5 .  Concluding.  Bemarks 

In  this  paper  we  presented  the  MINIBEL  data  base 
management  system.  It  is  implemented  and  running  on  the  IBM 
5100  desk-top  computer.  We  have  tested  the  system  with  a 
number  of  small  data  bases.  We  are  currently  generating  a 
data  base  for  the  records  of  Graduate  Students  in  the 
Department  of  Computer  Science  in  the  University  of  Toronto. 

There  is  nothing  different  or  exciting  in  technical 
terms  about  the  MINIBEL  implementation.  It  is  a  "garden 
variety"  limited  relational  system.  Its  main  feature  is  the 
ability  to  run  on  an  intelligent  terminal.  It  demonstrates 
that  front  end  intelligent  terminals  can  take  over  some  of 
the  DBMS  activity.  He  envision  in  future  DBMS  applications 
a  network  of  systems  with  some  data  base  activity  even  on 
very  small  local  data  base  nodes.  MINIBEL  operates  on  an 
IBM  5100  together  with  EDBS.  In  that  environment  there  is 
no  inherent  commercial  value.  It  demonstrates,  however, 
that  the  same  facility  could  possibly  be  implemented  with  a 
better  and  cheaper  terminal  together  with  a  large  DBMS, 
e.g.,  IMS. 
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Abstract 


In  the  past,  system  performance  measures  were  often  the 
sole  criterion  in  the  design  or  selection  of  a  DBMS.  Since 
DBMS's  are  designed  to  be  used  by  people,  user  performance 
measures  should  also  be  an  important  consideration.  In  this 
paper,  we  present  our  approach  to  the  modelling  and 
determination  of  the  user  performance  of  a  DBMS.  The  model 
consists  of  those  factors  expected  to  affect  user 
performance.  The  user  performance  is  measured  within  the 
framework  of  our  model  by  means  of  a  testing  methodology. 
Further  work  on  the  specification  of  the  model  and  the 


methodology  is  in  progress 
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1 ,  Introduction 

Data  base  management  systems  (DBHS’s)  are  designed  to 
help  their  users  cope  with  complex  data  handling  problems. 
To  perform  this  function,  a  DBMS  provides  two  major 
facilities  that  aid  the  user:  data  organization  and  data 
access  [ Tsichritzis  and  Lochovsky,  1977 J.  A  DBMS  helps  the 
user  define  and  store  his  data  by  allowing  him  to  organize 
it  according  to  a  logical  pattern.  This  logical  pattern  is 
called  a  data  model,  A  data  model  defines  rules  according 
to  which  data  may  be  grouped  and  groups  of  data  may  be 
related  to  each  other.  A  DBMS  helps  the  user  manipulate  his 
data  by  providing  a  means  of  accessing  the  data  without 
regard  to  its  physical  organization.  This  access  mechanism 
is  called  a  data  lan^ua^e.  A  data  language  permits  access 
to  the  user’s  data  according  to  the  organization  of  the  data 
as  specified  by  a  data  model, 

DBMS’s  did  not  spring  up  overnight.  They  are  a  product 
of  evolution  that  began  with  the  first  need  to  store  data 
for  an  extended  period  of  time.  At  first,  the  user  had 
complete  control  over  the  organization  and  access  of  his 
data.  The  data  were  only  used  by  him  and  so  could  be 
organized  and  accessed  to  suit  his  needs.  In  addition,  the 
user  usually  controlled  all  system  resources  whenever  he 
processed  his  data.  The  need  to  share  system  resources  led 
to  the  introduction  of  operating  systems  and  file  systems 
[Tsichritzis  and  Bernstein,  1974],  The  user  retained  a 
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certain  aaount  of  control  over  the  exact  organization  and 
access  of  his  data.  However,  the  exact  physical  placement 
of  the  data  and  its  access  was  now  relegated  to  the  file 
system.  File  management  systems  further  standardized  the 
organization  and  access  to  the  data  [Evans,  1971],  The  need 
to  share  data  among  several  users  meant  that  each  user  was 
perhaps  not  able  to  organize  and  access  his  data  exactly  as 
he  wanted.  Instead,  the  data  organization  and  access  was  a 
compromise  between  all  the  conflicting  user  needs.  Finally, 
DBMS’s  completely  standardize  both  the  organization  and  the 
access  of  the  data  [Tsichritzis  and  Lochovsky,  1977],  All 
the  users  see  the  data  organized  according  to  the  same  data 
model.  They  access  the  data  according  to  specific 
operations  as  defined  by  the  data  language. 

In  moving  from  the  early,  individual  type  of  data 
processing  to  DBMS’s,  the  user  has  lost  more  and  more 
control  over  his  environment.  In  the  beginning  he  was  able 
to  define  and  construct  his  own  environment.  Now  he  is 
presented  with  an  established  environment  that  he  has  to  use 
for  his  processing  needs.  Before,  the  user  could  construct 
his  environment  to  suit  his  needs.  Now,  he  must  suit  his 
needs  to  the  DBMS  environment. 

Because  of  the  evolutionary  nature  of  DBMS’s,  many  of 
their  facilities  tend  to  be  system  oriented.  In  the  past  it 
was  essential  to  maximize  the  performance  of  system 
resources.  Often  the  emphasis  on  the  system  oriented 
features  were  to  the  detriment  of  the  user  oriented  nature 
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of  DBMS  facilities.  Today,  the  cost  of  the  human  resources 
component  of  a  DBMS  operation  is  as  great  as,  if  not  greater 
than,  the  system  resources  component.  Therefore,  we  feel 
that  as  much  emphasis  should  be  given  to  user  performance  as 
to  system  performance  considerations, 

DBMS’s  are  meant  to  be  used  by  people.  As  such,  the 
facilities  that  they  provide  should  help  maximize  user 
performance  when  interacting  with  a  DBMS.  User  interaction 
with  a  DBMS  occurs  mainly  via  two  facilities:  the  data  model 
and  the  data  language.  The  user  oriented  nature  of  the  data 
model/data  language  (DMDL)  interface  determines,  to  a  large 
extent,  the  performance  of  a  user  when  interacting  with  a 
DBMS.  That  is,  the  environment  that  the  DBMS  presents  to 
the  user  affects  user  performance. 

The  D)M  DI  interface  of  today’s  DBMS’s  cannot  be  changed 
easily,  if  at  all.  This  is  due  in  part  to  the 
manufacturers’  investment  in  their  software  and  in  part  to 
the  users’  investment  in  their  application  programs.  When 
considering  a  DBMS  for  a  particular  application  it  is 
therefore  -important  to  measure  and  maximize  the  user 
performance  of  the  system.  As  far  as  we  know,  such  a 
measure  has  either  not  been  considered  in  the  past  or  only 
evaluated  qualitatively.  In  addition,  DBMS’s  of  the  future 
may  offer  several  DMDL  interfaces  to  their  users.  Again,  it 
will  be  important  to  choose  a  DMDL  interface  that  maximizes 
user  performance.  By  means  of  a  model  of  user  performance 
and  a  testing  methodology  within  the  proposed  model,  we  feel 
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that  a  quantitative  aeasure  of  user  performance  can  be 
obtained. 

2.  DBMS  Human  Factors  Testing 


Several  investigators  have  attempted  to  determine,  by 
observation,  the  factors  that  affect  the  performance  of 
users  of  computer  systems.  Eason  examined  users  during 
their  interaction  with  a  computer  system  [Eason,  1976  ].  He 
found  for  example  that  the  facilities  provided,  the  task  at 
hand,  the  user’s  job/role,  and  personal  factors  such  as 
motivation  were  major  factors  in  determining  user 
performance.  It  is  our  opinion  that  such  studies  often 
reveal  more  about  the  user  than  about  the  system  being 
studied.  Even  if  they  do  uncover  system  factors  related  to 
user  performance,  they  usually  cannot  show  in  what  manner  or 
to  what  degree  a  factor  affects  user  performance.  Such 
measurements  can  only  be  obtained  by  human  factors  testing. 


The  use  of  human  factors  testing  in  computer  science  is 
not  new.  A  great  deal  of  work  has  been  done  in  the 
programming  languages  area.  The  work  in  this  area  can  be 
categorixed  as: 


1.  Development  of  a  methodology  for  human  factors  testing 
of  programming  languages  [Weinberg  and  Schulman,  1974; 
Weissaan,  1974  ]; 

2.  Comparison  of  specific  languages  or  language  features 
[Sime  et  al. ,  1973;  Shneideraan  and  Ho,  1974;  Gannon,  1975]; 
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3,  Analysis  of  errors  made  in  programming  [Youngs,  1974]; 

4.  Analysis  of  the  programming  process  [Miller,  1974; 
Gould,  1975]. 

Some  work  on  human  factors  testing  of  DBMS's  has  also 
been  done  recently.  Thomas  and  Gould  have  evaluated  the 
query  language  Query  by  Example  [Thomas  and  Gould,  1975], 
They  determined  the  time  required  by  non-programmers  to 
learn  the  language  and  time  required  and  accuracy  of  coding 
queries.  In  this  manner,  they  measured  the  learnability  of 
the  language  for  a  certain  type  of  user. 

Reisner  has  performed  some  experiments  with  programmers 
and  non- programmers  comparing  the  SQUARE  and  SEQUEL 
languages  [Reisner  et  al. ,  1975].  The  purpose  of  the 
experiment  was  to  determine  the  good  and  bad  features  of 
each  language.  In  addition,  recommendations  were  made  to 
attempt  to  eliminate  the  cause  of  or  minimize  the  effect  of 
the  errors.  A  preliminary  model  of  query  complexity  and  two 
indices  of  query  complexity  were  also  proposed  [ Reisner, 
1976  ]. 


Work  on  human  factors  testing  in  programming  languages 
was  a  result  of  the  controversy  of  structured  programming 
techniques  as  an  aid  for  enhancing  user  performance. 
Recently,  a  similar  controversy  erupted  concerning  the 
merits  of  the  relational  and  network  DBMS  approaches  as 
related  to  user  performance.  This  controversy  has  focused 
attention  on  human  factors  testing  of  DBMS's.  The  nature  of 
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human  factors  testing  of  DBMS's,  while  similar  to 
programming  languages  also  has  its  differences. 

Programming  languages  testing  is  concerned  only  with 
language  features.  Many  of  these  language  features  are 
syntactic,  e.g.  ,  punctuation,  keywords,  rather  than 
semantic.  Because  of  the  interpretive  nature  of  data 
languages,  syntactic  properties  are  not  considered  overly 
important  since  they  can  usually  be  changed  easily.  Of  more 
concern  is  the  type  of  operations  provided  in  the  data 
language.  Another  important  aspect  in  DBMS's  is  the 
specific  data  model  or  data  model  features  provided.  That 
is,  what  data  models  or  data  model  features  enhance  user 
performance?  One  would  like  to  be  able  to  determine  if  one 
data  model  has  definite  advantages  over  another  data  model 
and  for  which  situations.  Note  that  if  abstract  data  types 
are  included  in  programming  languages  testing,  then  similar 
questions  can  be  asked,  i.e, ,  which  abstract  data  types  are 
usef u 1. 

It  is  much  more  likely  that  DBMS  facilities  will  be 
supplied  to  a  large  segment  of  the  population  via  public 
data  banks,  than  programming  languages.  As  the  use  of 
DBMS's  shifts  away  from  computer  and  technical  personnel  to 
so  called  casual  users,  the  nature  of  the  facilities 
supplied  to  the  user  has  come  under  question.  The  issue, 
however,  is  not  so  much  DBMS  approaches  as  the  question  of 
what  facilities  will  be  supplied  and  in  what  manner, 
particularly  within  the  DMDL  interface.  To  this  end,  human 
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factors  testing  can  be  used  to  evaluate  user  performance 
characteristics  of  different  DBMS  DMDL  interface. 

:  Models  and  Measures 

DBMS's  should  be  designed  and  selected  to  enhance  user 
performance.  However,  it  is  not  always  possible  to  tell 
intuitively  which  DBMS  features  contribute  to  or  detract 
from  user  performance.  For  example,  Reisner  discovered 
several  SFQDFL  concepts  that  adversely  affected  us€^r 
performance  f Reisner,  1976],  However,  it  was  not  obvious 
from  the  language  itself  that  this  would  be  the  case. 

So  far,  human  factors  testing  of  DBMS's  has  been 
confined  to  relational  systems.  In  addition,  only  data 
language  aspects  of  DBMS's  have  been  tested.  A  coD'.mon 
problem  with  both  programming  languages  and  DBMS  human 
factors  testing  is  the  inability  to  meaningfully  compare 
results  of  independent  investiaa tors.  The  results  are 
either  based  on  different  test  methods  or  the  test 
environment  is  not  the  same.  Therefore,  the  results  of 
different  experiments  often  appear  to  be  conflicting  or 
cannot  be  compared.  Programming  languages  and  DBMS  human 
factors  testing  lacks  a  unified  framework  within  which 
different  investigators  can  perform  their  research.  We 
believe  that  a  common  way  of  specifying  a  model  of  user 
performance  for  DBMS's  and  a  methodology  for  testing  for 
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user  performance  within  the  model  need  to  be  developed  to 
remedy  the  situation, 

3 . 1  Tow ar d  a  Model  of  User  Performa nee 

There  are  many  aspects  of  a  DBMS  that  influence  user 
performance,  e,g,,  system  response  time,  system 
documentation,  data  base  design,  data  model,  and  data 
language.  We  feel  that  the  most  important  of  these  is  the 
DMDL  interface  of  the  system.  The  DMDL  interface  dictates 
the  way  that  most  users  interact  with  the  facilities  of  the 
DBMS.  In  addition,  the  DMDL  interface  cannot  be  changed 
easily,  if  at  all.  In  systems  analysis  and  modeling 
research  a  model  of  system  performance  is  defined  and  the 
model  behaviour  is  tested  by  varying  its  parameters. 
Similarly,  we  believe  that  in  DBMS  human  factors  testing  it 
is  possible  to  define  formally  a  model  of  user  performance 
with  respect  to  the  DMDL  interface  and  to  test  the  model 
behaviour  by  varying  its  parameters. 

Consider  a  model  of  user  performance  containing  the 
parameters  data  model,  data  language,  user  type, 
application,  and  schema  description.  Notationally  the  model 
can  be  expressed  as 


UP  =  TM(DH,  DL,  UT,  A,  SD) 

where  UP  is  user  performance,  TM  is  the  testing  methodology, 
and  the  parameters  are  as  specified  above. 


We  believe  that 
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each  of  these  paraneters  affects  user  performance  in  some 
way.  Let  us  consider  each  parameter  in  turn. 

The  data  model  of  a  DBMS  defines  the  rules  according  to 
which  data  may  be  logically  grouped  and  groups  of  data 
related  to  each  other.  It  is  one  of  the  mechanisms  through 
which  the  user  interacts  with  the  stored  data.  If  we  are 
investigating  the  effect  of  a  data  model  on  user 
performance,  it  is  necessary  to  specify  the  models  under 
investigation  and  to  identify  the  properties  of  a  model  that 
we  expect  to  affect  user  performance. 

Data  models  can  be  characterized  by  their  properties 
[  Kershberg  et  al.,  1  976].  Consider  the  classification  graph 
theoretic  and  set  theoretic.  Each  group  can  be  further 
characterized  as  to  the  restrictions  pi  aced  on  their 
representational  capabilities.  For  example,  graph  theoretic 
data  models  may  allow  unrestricted  or  only  functional 
relationships.  Set  theoretic  data  models  may  allow 
arbitrary  sized  (n-ary)  tuples  or  only  binary  tuples.  The 
type  of  data  model  and  the  specific  restrictions  on  it  can 
be  expected  to  affect  user  performance.  The  effect  of 
specific  features  can  be  tested  by  holding  all  other  factors 
constant  and  only  varying  the  feature  in  question.  For 
example,  if  we  wanted  to  test  the  merits  of  graph  theoretic 
versus  set  theoretic  data  models  we  would  choose  specific 
instances  of  each  type.  We  would  then  hold  the  parameters 
DL,  OT,  A,  and  SD  constant  while  testing.  (Note  that 
notions  of  equivalence  may  have  to  be  defined  between 
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different  DL*s^  SD*s,  etc.  to  do  this.)  If  we  are  holding  DW 
constant  daring  testing,  then  it  is  important  to  be  able  to 
specify  DM  precisely  so  that  results  can  be  duplicated 
later.  By  specifying  precisely  the  properties  of  a  data 
model  we  consider  to  be  important  in  determining  user 
performance,  we  establish  a  framework  within  which  different 
investigations  can  be  performed. 


The  data  language  of  a  DBMS  is  the  means  by  which  a  user 
accesses  the  data  as  organized  by  a  data  model.  If  we  are 
investigating  the  effect  of  different  data  languages  on  user 
performance,  than  it  is  important  to  characterize  the  data 
language  completely.  One  property  of  a  data  language  that 
may  be  important  is  its  level  of  pr oced ura li ty .  A  data 
language  can  be  either  one  record  at  a  time  oriented  or  it 
can  be  set  oriented.  A  data  language  may  also  be  either  a 
self-contained  language  or  a  host  language.  Other 
properties  of  a  data  language  that  can  be  expected  to  affect 
user  performance  are  the  number  of  different  constructs  used 
and  the  naming  of  the  operations.  Again,  to  test  for 
different  data  languages  or  language  features,  we  would  hold 
all  parameters  except  DL  constant. 


The  user  type  of  a  DBMS  is  defined  as  the  sop 
of  the  user  that  is  interacting  with  the  DBMS 
types  of  users  can  be  identified,  e. g. , 
programmer,  specialists,  managers,  clerks,  etc. 
DMDL  interface,  the  performance  of  the  user  is 
depend  on  the  type  of  user.  For  example. 
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programmers  are  expected  to  show  a  higher  performance  level 
than  managers  for  most  current  DHDL  interfaces.  One  of  the 
important  issues  in  DBMS  design  is  identifying  what 
facilities  to  provide  for  a  certain  type  of  user.  Testing 
of  DHDL  interfaces  can  show  which  facilities  do  and  do  not 
contribute  to  user  performance. 
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The  schema  description  of  an  application  is  the 
definition  of  the  real-world  situation  in  terms  of  a  data 
model.  It  describes  the  entities  and  relationships  among 
the  entities  of  the  application.  Often  there  are  several 
ways  of  choosing  a  schema  for  an  application.  One  of  them 
may  be  more  effective  for  enhancing  user  performance.  Also, 
the  names  used  in  the  schema  description  can  affect  user 
performance.  Where  the  choice  of  a  schema  is  not  clear, 
human  factors  testing  can  reveal  a  preference. 

Our  model  of  user  performance  has  only  been  described 
informally  here.  To  formalize  it,  it  is  necessary  to 
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identify  all  paraneters,  rigorously  define  them,  specify  the 
properties  of  each  paraaeter  that  affect  user  performance, 
and  qualitatively  specify  how  the  properties  are  expected  to 
affect  user  perforaance.  Such  a  treatment  specifies  a  model 
of  user  performance  within  which  different  investigations 
can  be  performed  and  compared.  By  specifying  the  parameters 
of  an  investigation  and  which  one  is  being  varied,  it  is 
possible  to  characterize  different  human  factors 
experiments.  For  example,  Beisner's  experiment  was  a  data 
language  experiment  since  all  parameters  except  the  data 
language  were  held  constant.  In  particular,  it  tested  the 
notational  versus  the  English- like  aspect  of  a  data 
language.  Thomas  and  Gould’s  experiment  was  a  user 
performance  experiment  since  all  parameters  were  held 
constant.  Note  that  this  latter  experiment  is  essentially 
the  performance  evaluation  of  a  given  type  of  user  for  a 
DBHS. 


He  believe  that  the  specification  of  a  model  of  user 
performance  is  necessary  for  human  factors  testing  of 
DBMS’s.  Such  a  model  will  provide  the  first  step  toward  a 
unified,  formal  approach  to  human  factors  testing.  It  will 
also  help  ensure  the  reproducibility  of  results  and  allow 
comparison  of  different  investigations.  However,  a  model  of 
user  performance  is  not  enough  to  ensure  reproducibility  and 
comparability  of  results.  A  uniform  methodology  for  testing 
is  also  required  as  outlined  in  the  next  section. 
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3 . 2  Toward  a  Testing  Hethodoloqy 


Given  a  model  of  user  performance,  we  would  like  to 
determine  how  the  parameters  of  the  model  affect  the  model 
behaviour.  He  would  like  the  results  to  be  both 
reproducible  and  comparable.  For  results  to  be  reproducible 
means  that  given  the  same  parameter  specification  for  our 
model,  two  independent  administrations  of  the  same 
experiment  on  the  same  DBMS  should  produce  the  same  results 
(within  error  bounds).  For  results  to  be  comparable  means 
that  given  the  same  parameter  specifications  for  our  model, 
the  results  of  two  or  more  administrations  of  the  same 
experiment  on  different  DBMS's  can  be  meaningfully  compared. 
Reproducibility  and  comparability  are  ensured  by  a  common 
model  of  user  performance  and  by  a  common  testing 
methodology. 


A  preliminary  outline  of  a  methodology  for  human  factors 
testing  of  the  DMDL  interface  of  a  DBMS  has  been  described 
elsewhere  [ Lochovsky  and  Tsichritzis,  1976].  Briefly,  the 
methodology  consists  of  setting  up  the  experimental 
environment  to  ensure  constancy  of  parameters  not  being 
varied.  Tests  are  administered  in  a  controlled  manner  to 
determine  specific  measures  of  user  performance. 
Specifically,  tests  designed  to  measure  number  of  errors, 
persistence  of  errors,  ability  to  read  data  language 
programs,  and  ability  to  detect  and  correct  errors  have  been 
administered.  The  tests  were  administered  for  three 
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different 

DBMS’s  and 

correspon  di ng 

measures  of 

user 

performance 

related 

to 

the  data 

model 

parameter 

were 

o  btained. 

Reproducibi lity 

and  comparability 

of  results 

can 

be  demonstrated, 

A  final  component  of  the  methodology  involves  analysis 
and  interpretation  of  the  results  within  the  user  model.  To 
ensure  reproducibility  and  comparability,  results  must  be 
analysed  according  to  a  uniform  criterion.  We  feel  it  is 
possible  and  necessary  to  specify  guidelines  for  analysis  of 
results.  From  the  tests  performed  so  far,  some  preliminary 
guidelines  have  been  developed. 


Our  model  of  user  performance  and  our  testing 
methodology  while  related  can  also  be  considered  separately. 
Their  relationship  can  be  characterized  as  a  "black  box" 
with  inputs  and  outputs.  The  inputs  are  the  parameters  of 
our  model  of  user  performance.  The  outputs  are  the 
evaluation  of  the  user  performance.  The  black  box  is  our 
testing  methodology.  As  long  as  the  number  and  types  of 
inputs  and  the  black  box  remain  the  same,  the  outputs  are 
comparable.  However,  our  framework  allows  for  the 
substitution  of  different  inputs  and  black  boxes  (assuming 
compatibility  of  inputs  and  black  boxes.)  Thus  our  basic 
design  is  applicable  to  a  wider  area  than  merely  DBMS 
testi ng ,  e . g , , 


programming  languages 
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4,  Concluding  Beaarks 

We  believe  that  the  specification  of  a  model  of  user 
performance  and  a  methodology  for  testing  are  important  for 
several  reasons.  It  will; 

1.  help  formalize  and  unify  human  factors  testing  of 
DBMS  »  s; 

2,  provide  a  framework  for  comparing  different  DBMS’s  and 
different  DBMS  facilities; 

3.  demonstrate  the  feasibility  of  human  factors  testing  for 
DBMS  design  and  evaluation; 

4,  provide  a  basis  for  further  research  in  this  area. 

We  are  currently  working  on  a  complete  specification  of 
a  model  of  user  performance  and  a  testing  methodology  for 
the  model.  The  model  specification  includes  identification 
and  definition  of  all  relevant  parameters,  how  they  affect 


user  performance. 

and  in 

what  manner 

they 

can  be  varied. 

The  specification 

of  the 

methodology 

cf 

human  factors 

testing  includes  characterization  of  the  experiment,  control 
of  the  experimental  environment,  design  and  administration 
of  tests,  and  analysis  of  the  results.  The  feasibility  of 
the  user  model  and  methodology  will  be  demonstrated  by 
placing  the  experiments  performed  so  far  in  the  context  of 
our  user  model.  The  experiments  will  be  characterized 
according  to  the  parameter  of  user  performance  varied. 
Analysis  of  the  results  will  also  be  in  the  context  of  our 


user  model 
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We  feel  that  the  results  of  this  research  are  directly 
applicable  to  the  following  areas: 

1,  DBfIS  data  language  and  data  aodel  design; 

2.  DBBS  evaluation  and  selection* 

In  the  future,  these  areas  will  take  on  even  more  importance 
for  two  reasons*  First,  DBMS  facilitites  are  proposed  to  be 
made  available  to  a  large  part  of  the  population,  the  so 
called  casual  users  [Codd,  1974]*  It  will  be  important  to 
determine  what  facilities,  i.e.,  data  model  and  data 

language,  to  provide  to  these  users.  As  such,  our  user 

model  and  methodology  can  be  used  in  the  process  of  data 
model  and  data  language  design  of  casual-user  oriented  DMDL 
interfaces.  Second,  an  ANSI/SPAfiC  type  of  architecture  will 
probably  be  the  architecture  of  future  DBMS’s 
[  ANSI/X3/SPARC,  1975]*  ANSI/SPAEC  proposes  the  concept  of 
an  external  schema  for  each  application  of  an  organization* 
The  external  schemas  can  be  based  on  different  DMDL 
interfaces.  Given  a  choice,  it  will  be  important  to 
determine  which  DMDL  interface  is  most  appropriate  for  a 
given  application* 
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ABSTRACT 

Human  factors  as  well  as  system  related  considerations 
should  be  part  of  the  DBMS  selection  process.  However, 
appropriate  procedures  and  measures  for  human  factors 
testing  of  DBMS  facilities  are  lacking.  This  paper 
describes  a  methodology  and  proposes  a  set  of  measures  for 
human  factors  testing  of  the  data  model/data  language 
facilities  of  a  DBMS  as  they  relate  to  application  program 
development.  The  methodology  was  applied  to  three  DBMS's 
and  the  results  of  its  application  are  discussed. 
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1.  INTRODDCTION 


Many  organizations  today  are  turning  to  data  base 
management  systems  (DBMS)  to  improve  their  data  management 
facilities.  There  are  currently  many  commercial  systems 
each  offering  a  myriad  of  features.  The  choice  of  a  DBMS 
for  a  particular  application  and  user  environment  is  a 
difficult  and  not  altogether  clear-cut  process.  In  the 
past,  it  has  been  predicatei  mainly  on  system  efficiency 
considerations,  e, g. ,  throughput,  CPU  utilization,  storage 
optimization,  etc.  While  system  efficiency  is  certainly 
important,  the  main  raison  d’etre  of  DBMS's  is  to  facilitate 
user  interaction  with  a  data  base.  As  application  program 
development  and  maintenance  costs  escalate,  programmer 
effectiveness  must  be  maximized.  The  degree  to  which  a 
DBMS's  facilities  aid  the  user  in  efficiently  interacting 
with  a  data  base  will  be  called  its  user  effectiveness. 


Many  measures  have  been  devised  for  determining  system 
efficiency,  e.g.,  benchmarks,  CPU  and  disk  utilization,  I/O 
wait  time,  etc.  Comparable  measures  for  determining  a 
DBMS's  user  effectiveness  are  lacking.  In  this  paper,  we 
describe  a  methodology  for  determining  the  user 
effectiveness  of  one  aspect  of  a  DBMS.  Previous  work  in 
this  area  has  concentrated  on  data  language  testing  for 
language  design  and  evaluation  [1,2].  Our  goal  is  to 
develop  a  methodology  for  comparing  various  aspects  of  DBMS 
user  effectiveness.  In  this  way,  these  measurements  can 


become  part  of  the  DBMS  selection  process 
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2.  METHODOLOGY 

There  are  many  aspects  of  a  DBMS  that  influence  its  user 
ef fectiveness/  e.g,  system  response  time,  system 
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decide!  initially  to  compare  DBMS’s  in  terms  of  the  user 
effectiveness  of  their  DMDL  interface  facilities. 

Some  aspects  of  the  DMDL  interface  affecting  user 
effectiveness  are:  complexity  of  the  DMDL,  level  and  power 
of  the  data  language,  representation  capabilities  of  the 
data  model,  and  conciseness  and  readability  of  the  data 
language.  Our  methodology  addresses  itself  mainly  to  the 
first  aspect  although  the  other  aspects  all  influence  DMDL 
complexity.  It  is  also  necessary  to  consider  the  class  of 
users  when  measuring  DBMS  user  effectiveness.  The  same  DMDL 
interface  may  show  different  levels  of  user  effectiveness 
for  different  classes  of  users.  Our  methodology  is  designed 
mainly  to  measure  user  effectiveness  of  application 
programmers  although  it  can  be  easily  adapted  for  other 
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classes  of  users.  For  application  programmers,  DBMS  user 
effectiveness  is  important  mainly  for  two  types  of  activity; 
program  development  and  program  maintenance.  Our 
methodology  addresses  itself  to  the  former  activity. 


Application  program  development  requires  coding  and 
i uple mentation  of  programs  according  to  specified  criteria. 
To  measure  user  effectiveness  of  the  DMDL  interface 
facilities  for  application  program  development,  we  decided 
to  consider  the  following  factors: 

1.  proportion  of  correctly  coded  application  programs  for  a 
given  set  of  queries  and  a  given  application, 

2.  time  required  to  code  the  application  programs,  and 

3.  time  required  to  implement  the  application  programs. 

Our  methodology  is  based  on  determining  measures  for  these 
factors. 


These  three  factors  are  not  independent.  For  example,  a 
consistently  high  degree  of  correctness  in  coding  should 
lead  to  a  minimum  amount  of  coding  and  implementation  time. 
Coding  time  is  minimized  because  the  user  is  able  to  readily 
and  properly  use  the  DMDL  facilities  due  to  past  success. 
Implementation  time  is  minimized  because  a  minimum  amount  of 
time  is  spent  debugging  if  the  program  is  initially  correct. 
Alternatively,  a  consistently  low  degree  of  correctness  in 
coding  should  lead  to  longer  coding  and  implementation 
times.  Another  situation  that  might  arise  is  a  relatively 
short  coding  time  coupled  with  a  high  proportion  of 
incorrect  programs.  This  situation  indicates  an  inability 
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of  the  user  to  use  the  DMDL  interface  facilities  correctly. 
Exposing  the  reasons  for  these  dif f icultites  can  lead  to 
greater  user  effectiveness  of  the  DMDL  interface 
f acilitit es. 

Measures  of  DBMS  user  effectiveness  of  the  facilities  of 
different  DMDL  interfaces  for  a  given  application  and  user 
environment  are  obtained  from  a  series  of  carefully  planned 
DMDL  tests.  The  tests  measure  the  ability  of  the  user  to 
use  the  facilities  of  the  DMDL  interface  correctly.  The 
results  of  the  tests  are  not  absolute  measures  of  DBMS  user 
effectiveness.  They  are  a  comapartive  measure  of  DMDL 
interface  user  effectiveness  for  a  given  set  of  DBMS's,  a 
given  user  population,  and  a  given  application.  The  testing 
procedure  consists  of  the  following  series  of  steps. 

The  first  step  involves  selecting  subjects  and  assigning 
them  to  the  DMDL  interfaces  to  be  tested.  Subjects  are 
selected  to  reflect  an  accurate  cross  section  of  the 
intended  users.  Subjects  are  assigned  randomly  to  each  DMDL 
interface  to  be  tested.  A  subject  is  assigned  to  only  one 
DMDL  interface  and  works  with  that  DMDL  interface  throughout 
the  test  period.  Often,  a  subject  population  displays  non- 
uniform  characteristics.  For  example,  subjects  may  have 
different  lengths  and  types  of  programming  experience  or 
differnt  levels  of  knowledge  of  a  host  programming  language. 
Some  of  these  characteristics  may  influence  the  performance 
of  a  subject  during  testing.  It  is  therefore  desirable  to 
equalize  the  groups  as  much  as  possible  according  to  these 
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characteristics  to  insure  that  different  performance  levels 
between  groups  are  due  to  the  DHDL  interface  facilities  and 
not  subject  characteristics.  Subjects  can  be  categorized 
according  to  characteristics  expected  to  influence 
performance  and  then  randomly  assigned  to  each  DflDL 
interface  from  within  each  category.  In  this  way,  the 
influence  of  subject  performance  unrelated  to  DMDL  interface 
characteristics  is  minimized  among  groups. 

The  second  step  consists  of  familiarizing  the  subjects 
with  their  assigned  DMDL  interface.  Instruction  is  similar 
for  all  groups  within  the  constraints  of  the  different  DMDL 
interfaces.  Additional  general  knowledge  required  by  the 
subjects  is  obtained  prior  to  instruction  in  the  DHDL 
interface.  For  example,  if  a  host  language  is  required, 
then  all  subjects  obtain  sufficient  proficiency  in  the  host 
language. 


The  third  step  requires  the  subjects  to  code  a  set  of 
application  programs.  The  application  used  is  the  one  that 
will  be  used  in  the  actual  DBMS  environment,  e.g.,  payroll, 
inventory  control.  Each  group  uses  the  same  application, 
but  described  in  terms  of  that  group's  data  model.  The 
programs  require  each  group  to  use  its  DBMS's  data  language 
facilities  correctly  and  to  demonstrate  comprehension  of  the 
data  organization  features  of  the  corresponding  data  model. 
All  subjects  receive  the  same  English  language  statement  of 
a  program's  requirements.  Subjects  are  told  to  obtain  a 
logically  correct  program  that  implements  the  program 
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Steps  three  and  four  may  be  repeated  several  times  for 
the  same  application.  In  this  way  it  is  possible  to 
determine  if  user  effectiveness  is  influenced  by  familiarity 
with  and/or  use  of  the  DM DL  interface  facilities.  They  may 
also  be  repeated  for  different  applications  to  determine  if 
the  user  effectiveness  is  application  dependent. 

3.  APPLICATION  AND  RESULT 

Our  methodology  has  been  applied  to  measure  the 
comparative  user  effectiveness  of  the  DMDL  interface  of 
three  DBMS's.  The  DBMS's  are  part  of  the  Educational  Data 
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Base  System  (EDBS)  [3].  However,  their  DMDL  interface  is 
very  (Jifferent,  One  is  a  hierarchical,  another  a  network, 
and  the  third  a  relational  system.  However,  they  all  use 
the  same  host  language  (API)  and  the  same  terminal  system. 

The  EDBS  hierarchical  system  provides  a  data  model  and  a 
data  language  facility  similar  to  that  supported  by  IBM's 
IMS  [  4],  The  data  language  follows  closely  the  semantics  of 
the  IMS  data  language.  However,  where-clause  gua lif ica t ion 
replaces  segment  search  arguments  and  qualification  can  only 
be  at  one  hierarchical  level. 

The  EDBS  network  system  provides  a  data  model  and  data 
language  facility  based  on  the  CODASYL  DBTG  proposal  [5]. 
However,  the  data  language  does  not  support  some  of  the  DBTG 
features  and  supports  others  in  different  ways.  Only 
optional-manual  set  membership  is  permitted.  Where-clause 
qualification  is  used  instead  of  location  modes.  Records  of 
one  type  are  always  part  of  a  record  list  which  is  similar 
to  a  singular  set  in  the  DBTG  proposal.  Record  list 
retrieval  is  similar  to  set  membership  retrieval,  i.e., 
first,  last,  next,  and  prior.  Finally,  set  occurrence 
selection  and  set  switching  can  only  be  accomplished  by 
explicitly  altering  currency  indicators.  However,  a 
currency  indicator  can  only  change  to  the  value  of  another 
currency  indicator. 

The  EDBS  relational  system  provides  a  data  model  and 
data  language  facility  based  on  Codd’s  relational  data  model 
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and  ALPHA  data  lanqaage  [6].  The  data  language  supports  the 
relational  operations  projection,  restriction,  and  join. 
The  predicate  which  specifies  the  criterion  of  selection  is 
embodied  in  a  where-clause  qualification. 

The  three  DBMS’s  were  used  to  determine  their  user 
effectiveness  for  three  different  applications.  The  subject 
population  consisted  of  41  undergraduate  and  graduate 
students,  mainly  computer  science  majors.  The  subjects  were 
partitioned  according  to  previous  knowledge  of  APL  and 
previous  work  experience  as  professional  programmers. 
Subjects  were  then  assigned  to  one  of  the  DBMS’s  so  as  to 
equalize  the  groups  as  much  as  possible  according  to  the 
partitioning  criteria.  Because  it  was  not  possible  to 
supervise  all  subjects  during  the  implementation  step,  a 
special  volunteer  group  of  subjects,  one  for  each  DBMS,  was 
selected  to  act  as  a  control  group.  The  control  groups 
coded  and  implemented  their  programs  under  supervision  at 
one  session.  The  results  obtained  were  used  as  a  check 
against  the  reasonableness  of  the  results  obtained  from  the 
other  subjects. 
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Table  1 

Summary  of  results  for  all  tests 
(a)  Correctness  of  code  ('^) 
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- i - -j - i - 
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- + - + - ^ - 
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I_ 1 - J 


(b)  Mean  times  (min.) 
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Table  2 
Test  one 

(a)  Correctness  of  code  ( %) 

% 

\  Hierarchical  |  Network  J  Relational 

- i - h - 1 - 
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Table  3 
Test  two 

(a)  Correctnass  of  code  C^) 

1  Hierarchical  |  Network  j  Relational 


- - ^ - ^ - 

LC  1  50.0  I  57.1  j  57.7 

- .j - 4 - j - 

LI  I  50.0  1  42.9  I  42.3 

_ I _ I - 1 - 

(b)  Mean  times  (min.) 

j  Hierarchical  j  Network  J  Relational 

- ^ - 4 - 4 - 

coding  )  30  j  22  |  22 

i  rtple  menta  tion  1  54  j  48  |  86 


Table  4 
Test  three 

(a)  Correctness  of  code  C^) 


I  Hierarchical  ]  Network  ]  Relational 

- 4 - j - j - 

LC  J  60.  8  1  66.  1  J  86.5 
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- 1 - 1 _ 1 _ 
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4.  DISSCnSION  AND  ANALYSIS 

Overall,  the  relational  system  fared  the  best  in 
logically  correct  programs  followed  closely  by  the  network 
system.  However,  some  variation  is  shown  from  test  to  test. 
The  hierarchical  system  fared  worst  overall  and 


in  each 
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individual  test.  The  relational  and  network  syste 
fared  best  in  coding  and  implementation  time, 
hierarchical  system  (except  in  test  two)  shows  higher 
for  these  measures. 
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addition,  the  GET  UNIQUE  command  is  semantically  oriented  to 
individual  tree  entry  although  it  is  also  used  to  set  the 
position  pointer  when  navigating  across  trees.  The  second 
logic  error  involved  the  use  of  nested  GET  NEXT  WITHIN 
PARENT  commands.  The  GET  NEXT  WITHIN  PARENT  command  cannot 
be  used  in  this  manner.  The  final  logic  error  concerned 
failure  to  retrieve  all  data  that  met  a  specified  criterion. 
Subjects  were  unaware  or  did  not  understand  that  there  could 
be  multiple  occurrences  of  a  record  with  the  same  data 
values  or  that  there  could  be  many  children  records  of  one 
type  for  a  given  parent.  This  seems  to  be  a  difficulty  of 
translating  or  visualizing  the  template  for  a  hierarchical 
data  base,  i.e.,  the  hierarchical  definition  tree,  into  an 
actual  occurrence  of  a  data  base. 


Logic  errors  committed  by  the  network  group  fell  into 
two  categories.  First,  subjects  failed  to  check  for  set 
membership.  Because  set  membership  in  the  EDBS  network 
system  is  optional-manual,  it  is  necessary  to  check  for  set 
membership  when  initially  entering  a  set  occurrence  via  a 
record  of  the  member  record  type.  Failure  to  do  so  can 
result  in  currency  indicators  being  improperly  set.  Second, 
as  with  the  hierarchical  group,  some  network  system  subjects 
had  difficulty  understanding  that  there  could  be  multiple 
occurrences  of  a  record  with  the  same  data  values.  They 
also  had  some  difficulty  understanding  that  a  set  occurrence 
can  have  more  than  one  member  record. 
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fficulties  might  be  alleviated  by  data  language 
example,  renaming  the  GET  UNIQHE  command  of 
ical  system  GET  FIRST  might  reduce  the  failure 
set  the  position  pointer  correctly.  Also,  a 
r  command  may  be  helpful.  Allowing  nested  GET 
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NEXT  WITHIN  PARENT  commands  by  specifying  the  pa 
interest  might  reduce  these  errors.  Retestin 
applying  these  recommendations  would  indicate  whethe 
changes  are  adequate  to  effectively  deal  with  the  pr 
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5,  SUMMARY 

The  objectives  of  the  research  described  in  this  paper 
were  twofold.  First,  we  wanted  to  develop  a  methodology  for 
comparing  different  DBMS's  according  to  the  user 
effectiveness  of  certain  aspects  of  thier  DMDL  interface. 
Second,  we  wanted  to  apply  the  methodology  to  some  existing 
DBMS's  for  some  particular  applications  to  demonstrate  its 
feasibility.  Experimental  testing  indicates  that  it  is 
possible  to  ascertain  comparative  user  effectiveness  of 
different  DMDL  interface  for  a  given  application. 

We  also  discovered  that  error  analysis  of  human  factors 
testing  can  reveal  which  aspects  of  a  DMDL  interface  pose 
difficulties  for  users.  Such  revelations  could  lead  to 
language  changes  and/or  instructional  changes  to  correct  the 
problem  [7].  Thus,  human  factors  testing  can  help  improve 
the  user  effectiveness  of  operational  DBMS  installations  as 
well  as  aid  in  the  selection  of  a  DBMS. 

A  final  word  of  caution  is  advised  in  interpreting  and 
applying  our  experimental  results.  They  should  not  be 
interpreted  as  a  general  comparison  of  DMDL  interfaces  or  as 
applicable  to  all  applications  and  user  environments.  They 
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show  only  the  comparative  user  effectiveness  of  the  three 
EDBS  DBMS's  for  the  applications  tested.  Thus,  although  our 
methodology  is  applicable  to  all  DBMS's  and  all  user 
environments,  the  results  obtained  by  its  application  are 
only  valid  for  the  DBMS's  tested  and  only  for  the  particular 
user  environment  in  which  it  is  applied. 
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AN  EDUCATIONAL  DATA  BASE  MANAGEMENT  SYSTEM 

F.  Lochovsky  and  D.  Tsichritzis,  May  1974  f INFOR, 
to  appear] 

*  CSRG-34 

ALLOCATING  STORAGE  IN  HIERARCHICAL  DATA  BASES 

P.  Bernstein  and  D.  Tsichritzis,  May  1974  f Inf ormation 
Systems  Journal,  v,  1,  pp,  133-140  ] 

*  CSRG-35 

ON  IMPLFMFNTATION  OF  RELATIONS 

D.  Tsichritzis,  flay  1974 

*  CSRG-36 

SIX  PL/T  COMPILERS 

D.B.  Wortman,  P.J.  Khaiat,  and  D.M.  Lasker,  August  1974 
[Software  Practice  and  Experience,  v .  6,  ii.3, 

July-Sept.  1976] 

*  CSRG-37 

A  METHODOLOGY  FOR  STUDYING  THE  PS YCHOLOGICA L  COMPLEXITI 

OF  COMPUTER  PROGRAMS 

Laurence  M.  Weissman,  August  1974 
fPh.D.  Thesis,  DCS,  1974] 

*  CSRG-38 

AN  INVESTIGATION  OF  A  NEN  METHOD  OF  CONSTRUCTING 

SOFTWARF 

David  M,  Lasker,  September  1974  [M.Sc.  Thesis,  DCS,  1974] 

CSaG-39 

AN  ALGEBRAIC  MODEL  FOR  STRING  PATTERNS 

Glenn  F.  Stewart,  September  1974  [M.Sc.  Thesis,  DCS,  1974] 

CSRG-40 

EDUCATIONAL  DATA  BASE  SYSTEM  USER'S  MANUAL 

J.  Klebanoff,  F.  Lochovsky,  A.  Rozitis,  and 

D.  Tsichritzis,  September  1974 

♦  CSRG-41 

NOTES  FROM  A  WORKSHOP  ON  THE  ATTAINMENT  OF 

RELIABLE  SOFTWARE 

David  B.  Wortman  (cd.),  September  1974 

♦  CSEG-42 

THE  PROJECT  SUE  SYSTEM  LANGUAGE  REFERENCE  MANUAL 

B.L.  Clark  and  F.J.B.  Ham,  September  1974 
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CSRG-43 

A  DATA  BASE  PROCESSOR 

E.A,  Ozkarahan,  S.A,  Schuster  and  K.C,  Smith, 

November  1974  [Proceedings  National  Computer 

Conference  1975,  v. 44,  pp. 379-388] 

♦  CSRG-44  MATCHING  PROGRAM  AND  DATA  REPRESENTATION  TO  A 

COKPDTTNG  ENVIRONMENT 

Eric  C.R.  Hehner,  November  1974  [Ph.D.  Thesis,  DCS,  1974] 

♦  CSBG-45  THREE  APPROACHES  TO  RELIABLE  SOFTWARE;  LANGUAGE 


DESIGN,  DYADIC  SPECIFICATION,  COMPLEMENTARY  SEMANTICS 

J.E.  Donahue,  J. D.  Gannon,  J.V.  Guttag  and 

J.J.  Horning,  December  1974 

CSRG-46 

THE  SYNTHESIS  OF  OPTIMAL  DECISION  TREES  FROM 

DECISION  TABLES 

Helmut  Schumacher,  December  1974 
[M.Sc.  Thesis,  DCS,  1974] 

CSHG-47 

LANGUAGE  DESIGN  TO  ENHANCE  PROGRAMMING  RELIABILITY 

John  D.  Gannon,  January  1975  [Ph.D.  Thesis,  DCS,  1975] 

*  CSRG-48 

DETERMINISTIC  LEFT  TO  RIGHT  PARSING 

Christopher  J.M.  Turnbull,  January  1975 
[Ph.D.  Thesis,  EE,  1974] 

CSRG-49 

A  NETWORK  FRAMEWORK  FOE  RELATIONAL  IMPLEMENTATION 

D.  Tsichritzis,  February  1975  [in  Data  Base 

Description,  Dongue  and  Nijssen  (eds.).  North 

Holland  Publishing  Co.  ] 

*  CSRG-50 

A  UNIFIED  APPROACH  TO  FUNCTIONAL  DEPENDENCIES 

AND  RELATIONS 

P.A,  Bernstein,  J.R.  Swenson  and  D.C.  Tsichritzis 

February  1975  [Proceedings  of  the  ACM  SIGMOD  Conference, 

1  975  ] 

*  CSRG-51 

ZETA:  A  PROTOTYPE  RELATIONAL  DATA  BASE 

MANAGEMENT  SYSTEM 

M.  Brodie  (ed) .  February  1975  [Proceedings  Pacific 

ACM  Conference,  1975] 

♦  C3RG-52 

AUTOMATIC  GENERATION  OF  SYNTAX-REPAIRING  AND 

PARAGRAPHING  PARSERS 

David  T.  Barnard,  March  1975  [M.Sc.  Thesis,  DCS,  1975] 

♦  CSEG-53 

QUERY  EXECUTION  AND  INDEX  SELECTION  FOR  RELATIONAL 

DATA  BASES 

J.H.  Gilles  Farley  and  Stewart  A,  Schuster,  March  1975 

CSRG-54 

AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER 

PROGRAM  ENGINEERING 

J.V.  Guttag  (ed.).  Third  Edition,  April  1975 

CSRG-55 

STRUCTURED  SUBSETS  OF  THE  PL/1  LANGUAGE 

Richard  C.  Holt  and  David  B.  Wortman,  May  1975 
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CSRG-56  FEATURES  OF  A  CONCEPTUAL  SCHEMA 

D.  Tsichritzis,  June  1975  [ Proceedinqs  Very  Large 
Data  Base  Conference,  1975] 

♦  CSEG-57  MERLIN:  TOWARDS  AN  IDEAL  PROGRAMMING  LANGUAGE 
Eric  C. B.  Hehner,  July  1975 

CSRG-58  ON  THE  SEMANTICS  OF  THE  RELATIONAL  DATA  MODEL 
Hans  Albrecht  Schmid  and  J.  Richard  Swenson, 

July  1975  r Proceedings  of  the  ACM  SIGMOD  Conference, 
1975  ] 

CSRG-59  THE  SPECIFICATION  AND  APPLICATION  TO  PROGRAMMING 


OF  ABSTRACT  DATA  TYPES 

John  V.  Guttag,  September  1975  [ Ph. D.  Thesis,  DCS,  1975] 

CSRG-60 

NORMALIZATION  AND  FUNCTIONAL  DEPENDENCIES  IN  THE 
RELATIONAL  DATA  BASE  MODEL 

Phillip  Alan  Bernstein,  October  1975 
[Ph.D.  Thesis,  DCS,  1975] 

CSRG-61 

LSI:  A  LINK  AND  SELECTION  LANGUAGE 

D.  Tsichritzis,  November  1975  [Proceedings  ACM 

SIGMOD  Conference,  1976] 

CSRG-62 

COMPLEMENTARY  DEFINITIONS  OF  PROGRAMMING 

LANGUAGE  SEEANTICS 

James  E.  Donahue,  November  1975 
[Ph.D.  Thesis,  DCS,  1975] 

CSRG-63 

AN  EXPERIMENTAL  EVALUATION  OF  CHESS  PLAYING 

HEURISTICS 

Lazio  Sugar,  December  1975  [M.Sc.  Thesis,  DCS,  1975] 

CSRG-64 

A  VIRTUAL  MEMORY  SYSTEM  FOR  A  RELATIONAL 

ASSOCIATIVE  PROCESSOR 

S.A.  Schuster,  E.  A.  Ozkarahan,  and  K.C.  Smith, 

February  1976  [Proceedings  National  Computer 

Conference  1976,  v. 45,  pp. 855-862] 

CSRG-65 

PERFORMANCE  EVALUATION  OF  A  RELATIONAL 

ASSOCIATIVE  PROCESSOR 

E.A.  Ozkarahan,  S.A.  Schuster,  and  K.C.  Sevcik, 

February  1976  [  ACM  Transactions  on  Database 

Systems,  v.1,  n:4,  December  1976] 

CSRG-66 

EDITING  COMPUTER  ANIMATED  FILM 

Michael  D.  Tilson,  February  1976 

[M.Sc.  Thesis,  DCS,  1975] 

CSRG-fv7  A  DIAGRAMMATIC  APPROACH  TO  PROGRAMMING  LANGUAGE 
SEMANTICS 

James  H.  CorHy,  March  1976  [M.Sc.  Thesis,  DCS,  1975] 


CSRG-68 

A  SYNTHETIC  ENGLISH  QUERY  LANGUAGE  FOR  A 

RELATIONAL  ASSOCIATIVE  PROCESSOR 

L. Ke rsc hber g ,  E.A.  Ozkarahan,  and  J.E.S.  Pacheco 

April  1976 
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CSRG-69  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM  ENGINEERING 

D.  Barnard  and  D,  Thompson  (Eds.),  Fourth  Edition,  May  1976 

CSRG-70  A  TAXONOMY  OF  DATA  MODELS 

L.  Kerschberg,  A,  Klug,  and  D.  Tsichritzis,  May  1976 
[  Proceadinqs  Very  Large  Data  Base  Conference,  1976') 

CSRG-71  OPTIMIZATION  FEATURES  FOR  THE  ARCHITECTURE  OF  A 
DATA  BASE  MACHINE 

E. A.  Ozkarahan  and  K. C.  Sevcik,  May  1976 

CSRG-72  THE  RELATIONAL  DATA  BASE  SYSTEM  OMEGA  -  PROGRESS  REPORT 
H.A.  Schmid  (ed.),  P.A.  Bernstein  (ed.),  B.  Arlow, 

R.  Baker  and  S,  Pozgaj,  July  1976 

CSRG-73  AN  ALGORITHMIC  APPROACH  TO  NORMALIZATION  OF 
RELATIONAL  DATA  BASE  SCHEMAS 
P.A,  Bernstein  and  C.  Beeri,  September  1976 

CSRG-74  A  HIGH-LEVEL  MACHINE-ORIENTED  ASSEMBLER  LANGUAGE 
FOR  A  DATA  EASE  MACHINE 

E.A.  Ozkarahan  and  S, A.  Schuster,  October  1976 


CSRG-75  DO  CONSIDERED  OD:  A  CONTRIBUTION  TO  THE 
PROGRAMMING  CALCULUS 
Eric  C, R.  Hehner,  November  1976 

CSRG-76  "SOFTWARE  HUT":  A  COMPUTER  PROGRAM  ENGINEERING 
PROJECT  IN  THE  FORM  OF  A  GAME 
J.J.  Horning  and  D.B.  Wortman,  November  1976 

CSRG-77  A  SHORT  STUDY  OF  PROGRAM  AND  MEMORY  POLICY  BEfLAVIOUR 
G.  Scott  Graham,  January  1977 


